Tech News
← Back to articles

Show HN: Continuous Claude – run Claude Code in a loop

read original related products more articles

Automated workflow that orchestrates Claude Code in a continuous loop, autonomously creating PRs, waiting for checks, and merging - so multi-step projects complete while you sleep.

This all started because I was contractually obligated to write unit tests for a codebase with hundreds of thousands of lines of code and go from 0% to 80%+ coverage in the next few weeks - seems like something Claude should do. So I built Continuous Claude, a CLI tool to run Claude Code in a loop that maintains a persistent context across multiple iterations.

Current AI coding tools tend to halt after completing a task once they think the job is done and they don't really have an opportunity for self-criticism or further improvement. And this one-shot pattern then makes it difficult to tackle larger projects. So in contrast to running Claude Code "as is" (which provides help in isolated bursts), what you want is to run Claude code for a long period of time without exhausting the context window.

Turns out, it's as simple as just running Claude Code in a continuous loop - but drawing inspiration from CI/CD practices and persistent agents - you can take it a step further by running it on a schedule or through triggers and connecting it to your GitHub pull requests workflow. And by persisting relevant context and results from one iteration to the next, this process ensures that knowledge gained in earlier steps is not lost, which is currently not possible in stateless AI queries and something you have to slap on top by setting up markdown files to store progress and context engineer accordingly.

While + git + persistence

When you have a task that is too complex to complete 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 down the task into many small tasks (e.g., only document this one file first, then the rest of the folder, and so on). So all you need is a while loop that stops eventually, a version control and PR reviews integrations, and a persistent context mechanism.

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

This loop runs Claude Code with the prompt that the user supplies but also explicitly tells the model: "This is part of a continuous development loop... you don't need to complete 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 that it should aim for incremental progress, not rush to finish everything at once.

The script handles also the git operations around the code changes. For each loop, it creates a new branch, generates the commit, pushes it, and creates a pull request using GitHub's CLI. Next step is monitoring and control: it enters a time-interval loop where it periodically checks the status of CI checks and reviews on that PR using gh pr checks and waits for the PR to get all green statuses and required approvals. 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 a merge queue.

Should an iteration fail, it can just close the PR, delete the branch, and disregard the work. This is indeed wasteful, but now with knowledge of the test failures, the next attempt can choose to try something different. And because it piggybacks on top of GitHub, you can combine things like code review and preview environments without any additional work, for example if the repo requires at least one code owner review or has specific CI checks that must pass, it will simply be constrained by those and will not merge until they are satisfied.

... continue reading