AnandChowdhary/continuous-claude: 🔂 Run Claude Code in a continuous loop, autonomously creating PRs, waiting for checks, and merging

It all started because I was contractually obligated to write unit tests for a codebase containing hundreds of thousands of lines of code and go from 0% to 80%+ coverage over the next few weeks – it seems like something the cloud should do. So I created Continuous Cloud, a CLI tool to run the cloud code in a loop, maintaining a persistent context across multiple iterations.

Current AI coding tools stop after completing a task when they feel the work is complete and don’t really have the opportunity for self-criticism or further improvement. And this one-shot pattern makes it hard to tackle larger projects. So as opposed to running the cloud code “as is” (which helps in separate bursts), what you want is to run the cloud code for a long time without terminating the context window.

Turns out, it’s as simple as running cloud code in a continuous loop – but taking inspiration from CI/CD practices and persistent agents – you can take it a step further by running it on a schedule or via triggers and connecting it to your GitHub pull request workflow. And by persisting relevant context and results from one iteration to the next, this process ensures that the knowledge gained in earlier steps is not lost, which is not currently possible in stateless AI queries and you have to slap on top of that by setting up Markdown files to store the progress and context the engineer is using.

When you have a task that is too complex to accomplish in a single step, for example migrating from Next.js to Tanstack Start or adding documentation for a previously undocumented codebase, you need to break the task into several smaller tasks (for example, document just this one file first, then the rest of the folder, and so on). So all you need is a time loop that eventually closes, a version control and PR review integration, and a perpetual reference mechanism.

I wrote a bash script that acts as the conductor, repeatedly invoking the cloud code with appropriate prompts and handling the surrounding tooling. The script accepts a prompt (task description), the maximum number of iterations to run, and repository information (owner and repo name for GitHub integration). When initiated, it goes into a loop (potentially infinite), where each loop iteration corresponds to a cloud of effort of one unit of work towards the overall goal.

This loop runs the cloud code with the prompts that the user provides but explicitly tells the model: “This is part of a continuous development loop… You don’t need to accomplish the entire goal in one iteration, just make meaningful progress on one thing, then leave clear notes for the next iteration (human or AI)… Think of it as a relay race where you’re passing the baton.” This sets the right expectations for the model in that it should aim for incremental progress, not rush to finish everything at once.

The script also handles Git operations around code changes. For each loop, it creates a new branch, generates a commit, pushes it, and creates a pull request using GitHub’s CLI. The next step is monitoring and controlling: it enters a time-interval loop where it periodically checks the status of the CI probe and reviews that PR using gh pr checks And the PR waits for all green statuses and necessary approvals to be received. If everything looks good (tests passed, etc), it merges the PR, then pulls the updated main branch and cleans up the local feature branch, so essentially implementing the merge queue.

If an iteration fails, it can simply close the PR, delete the branch, and ignore the task. This really sucks, but now with the knowledge of the test failures, the next attempt may choose to do something different. And because it’s on top of GitHub, you can add things like code review and preview environments without any extra work, for example if the repo requires review by at least one code owner or has specific CI checks it must pass, it will simply be intercepted by them and won’t merge until they’re satisfied.

It is a common practice to use a shared persistent Markdown file like TASKS.md to maintain context consistency between different agents working on the same task. Its MVP is just a single file that acts as an external memory where the cloud can record what it has done and what needs to be done next, any new information or mistakes, etc.

The default prompt includes guidelines about what these notes should contain: they should be concise and action-oriented, focus on context that will help in the next step, and should not form a verbose log or include information that could be extracted from code or test results on GitHub. Without these specific hint instructions, it will go rogue and create a really long file that hurts more than helps, when the intent is to keep the notes as a neat handoff package between runs.

An actual production example I saw was where the previous iteration said “Note: I attempted to add tests to I think you can certainly have a better mechanism, but I found that a smaller file already reduces the chance of context drift, where it can forget earlier logic or work and go around in circles.

I’m not sure yet whether I want this file to be checked into the git commit history or not. This file acts as an external scratchpad to the cloud, giving it a long-term memory that survives beyond the context window of any single invocation, so one could argue that it makes sense to have a more sophisticated system that can manage multiple tasks while tracking changes to the living document, but I’m not sure yet. Either way, the trade-off is that the notes rely on the cloud to maintain them faithfully (as I see it would usually because of the hint).

I was wondering what some other use cases might be for this. Tools like Renovate and Dependabot were the first to come to mind, while Continuous Code is not limited to just dependencies and is also capable of fixing post-update issues. So you can run a GitHub Actions workflow that runs every morning, checks for dependency updates, and then continuously makes updates to the codebase based on the dependency’s release notes until you’re completely green again.

Additionally tasks like breaking the monolith into modules, modernizing callbacks to async/await, or updating the code to new style guidelines can be done step by step. For example, it could execute a series of 20 pull requests over a weekend, each would be part of a refactor, and each PR would have to pass all testing/CI. There is a whole range of tasks that are very ordinary to us but still require attention to avoid breaking the build – is this how we can address technical debt?

In general, I think the model of running the coding agent in a loop better reflects human development practices and avoids the common pitfalls of trying to solve everything at once; Even with planning mode, I think iterative refinement is the way to go for larger tasks. Plus, depending on your appetite, the system can be as human-in-the-loop as you want. Cloud code handles the grunt work of coding and iteration, but humans stay in the loop through familiar mechanisms like reading PR reviews and Markdown notes.

Sustainable Cloud emphasizes small, incremental changes rather than giant leaps. Download the CLI from GitHub to get started!