Continuous Claude: Running Claude Code in a PR loop until the job is done

The problem: one shot Claude Code stops too early for big jobs

The README frames the origin plainly: the author was contractually obligated to take a codebase of hundreds of thousands of lines from 0% to 80%+ test coverage in a few weeks. That is not a task you finish in one prompt. The stated weakness of current AI coding tools is that they halt once they believe the task is done, with no built in chance for self-criticism or further improvement. The one-shot pattern is what makes larger projects hard.

The tool is aimed at that gap. It is for engineers who have a goal that can be described in one sentence and checked by a machine, and who are willing to let a process churn on it across many attempts. The README lists the shapes of work it suits: dependency updates where breaking changes must be fixed from release notes, breaking a monolith into modules, converting callbacks to async/await, updating to new style guidelines. It also names the class of work directly: tasks too mundane for humans but still requiring attention so the build does not break.

While plus git plus a markdown file: the actual mechanism

The first version was a while loop that called claude with --dangerously-skip-permissions and a prompt, then slept one second. The tool grew from that. A Bash script acts as conductor, repeatedly invoking Claude Code and handling the surrounding tooling. For each iteration the README describes five steps: create a new branch and run Claude Code to generate a commit; push and create a pull request with GitHub's CLI; monitor CI checks and reviews via gh pr checks; merge on success or discard on failure; pull the updated main branch, clean up, and repeat.

Failure handling is the part worth reading twice. When an iteration fails, the script closes the PR and discards the work. The README calls this wasteful and argues the next attempt can try something different because it knows about the test failures. Because the loop rides on GitHub's existing workflows, you get code review and preview environments without extra work, and repository rules such as code owner approval or required checks are respected.

Context continuity is the second mechanism, and it is not a vector store. A shared markdown file is external memory where Claude records what it did and what should come next. The README notes that without specific prompting it would write verbose logs that hurt more than help, so the instruction is to treat notes as a clean handoff: make meaningful progress on one thing, then leave clear notes for the next iteration, described as a relay race where you pass the baton. A production example in the README shows one iteration ending with a note about a failed edge case and a null input in a function, and the next invocation prioritising exactly that.

Installing Continuous Claude and running a first loop

The repository ships two installer scripts at the top level, install.sh and install.ps1, alongside the two main scripts continuous_claude.sh and continuous_claude.ps1 and their .sha256 checksum files. The README does not spell out the installer arguments, so the honest starting point is the repository root: run the installer for your platform and expect the shell script on Unix-like systems and the PowerShell script on Windows. The checksum files exist to verify the downloaded scripts.

bash install.sh

After that, the loop is driven by the script itself. The README does not document a full flag list, so treat the invocation as the entry point rather than a finished reference.

./continuous_claude.sh

The conceptual prompt shape comes from the README's own first version, which is the clearest example of what the model is told on each pass. The important part is the instruction to make partial progress and leave notes.

while true; do
  claude --dangerously-skip-permissions "Increase test coverage [...] write notes for the next developer in TASKS.md, [etc.]"
  sleep 1
done

What you should see: a branch created, a commit, a pull request opened with the GitHub CLI, and then the script polling checks with gh pr checks. On green, the PR is merged and main is pulled. On red, the PR is closed and the work is thrown away. Before any long run, open one throwaway PR by hand and confirm gh pr checks prints the check names you expect, because the loop decides success from that output.

The failure mode is deliberate waste, and it is not free

Discarding a failed iteration is the design, not a bug, and the README says so. The cost is real: every failed iteration spends tokens, CI minutes and wall clock on work that is deleted. The README's own framing is that this wasteful-but-effective approach becomes viable as token costs approach zero. If your token budget is not close to that, the economics change and the loop becomes an expensive way to generate closed pull requests.

A second boundary is the verification step. The loop merges on success, and success is defined by the checks GitHub reports. If your repository has thin or absent CI, the conductor has nothing meaningful to gate on and will merge whatever the model produced. That makes the tool the wrong choice for work whose quality cannot be reduced to a passing pipeline.

A third: the script runs Claude Code with --dangerously-skip-permissions in the README's own example. That is an unattended agent with broad permissions on your checkout. The repository rules you already have, such as required checks or code owner approval, are the guardrail, and if you have none, you have none.

The README also mentions running specialised agents at the same time, one for development, one for tests, one for refactoring, and immediately flags the coordination problem it introduces. The author writes that he is trying a similar approach for adding tests in different parts of a monorepo at the same time. That is an experiment, not a documented feature.

How it differs from Dependabot and from GitHub Next agentics

Dependabot is the closest everyday comparison and the README draws it explicitly. Dependabot opens a dependency update and stops there. Continuous Claude is positioned as the layer that also fixes the breaking changes after an update by reading release notes, running in a workflow every morning, and iterating until tests pass. The difference is scope: one is a version bump, the other is a repair loop around the bump.

GitHub Next's agentics project is a different approach to the same family of problem. According to the README, agentics combines an explicit research phase with pre-build steps so the software is restored before agentic work begins. Continuous Claude has no separate research phase; it starts from the shared markdown notes and the previous iteration's outcome. Don Syme of GitHub Next is quoted in the README on fault tolerance: if things go wrong the run hits resource limits and tries again, or the user throws the generated PR away. That tolerance of thrown-away work is the shared premise of both projects, but agentics puts more structure before the agent starts, and Continuous Claude puts more weight on the pull request as the unit of work.

Maintenance, licence and what the loop costs to keep running

The repository is not archived, and the last push was on 2026-08-24, so it is close to current. Releases are frequent and small: v0.24.8 on 2026-07-13, with v0.24.7 and v0.24.6 both on 2026-05-09. The version number is still below 1.0, which is a fair signal that interfaces can move. Two platform scripts plus checksum files means upgrades are a reinstall of the script rather than a package manager transaction, and the README does not document rollback or pinning to an older release, so keep the previous copy if you need to go back.

The licence is MIT, and the LICENSE file sits at the repository root. That is permissive and places few obligations on how you redistribute or modify the script. It says nothing about the terms of the Claude Code CLI itself, which is a separate product with its own usage terms, and nothing about GitHub Actions or runner billing, which is where the CI minutes from discarded iterations land. Those are the costs to check before committing to an overnight run, not the licence.

Editorial conclusion

Adopt Continuous Claude if you have a long, verifiable grind task such as raising test coverage in a large repo, a GitHub remote with CI that gates merges, and a tolerance for wasted iterations when a PR is closed and discarded. Do not adopt it if you want a human reviewing each change before it lands, if your work has no automated check to decide success, or if you cannot run Claude Code with skipped permissions. Before the first long run, verify three things in your own repository: that gh pr checks reports the checks you expect on a throwaway PR, that the shared notes file is being written and read between iterations, and that the default branch protection rules and code owner requirements behave the way you want when a bot opens a PR.

Frequently asked questions

Official sources

1. AnandChowdhary/continuous-claude on GitHub
2. License: MIT
3. Project website
4. README
5. Releases