Continuous Claude: a Bash conductor that turns Claude Code into a PR-per-iteration loop

The job Continuous Claude was built for

The README opens with the origin story: the author was contractually obligated to write unit tests for a codebase of hundreds of thousands of lines and move coverage from 0% to 80% or more within a few weeks. That is the shape of problem the tool targets. It is not a general coding assistant and it is not a replacement for an editor plugin. It is for work that is too large for one prompt and too repetitive to be interesting, where each unit of progress is small enough to land as its own pull request.

The author frames the gap plainly: current AI coding tools tend to halt once they believe the task is done, with no room for self-criticism or further improvement, and that one-shot pattern makes larger projects hard. So the intended user is an engineer with a long backlog of mechanical changes and a repository that already enforces quality through CI. The README names refactors such as breaking a monolith into modules, moving callbacks to async/await, or applying new style guidelines, and suggests a run could produce twenty pull requests over a weekend. It also positions the tool against dependency updaters: Dependabot can bump a version, but Continuous Claude can read release notes and keep fixing the resulting breakage until tests pass.

While plus git plus persistence: the actual loop

The first version was a shell one-liner, quoted in the README, that ran claude --dangerously-skip-permissions with a prompt telling it to increase test coverage and write notes for the next developer in TASKS.md, then slept for a second and repeated. The shipped tool keeps that skeleton and adds the surrounding plumbing. The Bash script acts as the conductor, invoking Claude Code repeatedly and handling everything around it.

The README lists five steps per iteration. The script creates a new branch and runs Claude Code to generate a commit. It pushes the branch and opens a pull request using GitHub's CLI. It monitors CI checks and reviews through gh pr checks. It merges on success or discards on failure. Then it pulls the updated main branch, cleans up, and repeats.

The important architectural choice is that the pull request is the unit of work and the merge is the reward signal. Because the loop piggybacks on GitHub's existing workflows, the README notes you get code review and preview environments without extra work, and that required code owner approval or specific CI checks are respected. That cuts both ways: the loop is only as good as the checks you already have. A repository with a permissive CI configuration gives the agent nothing to fail against, and the merge step becomes a formality.

Failure handling is deliberately wasteful. When an iteration fails, the script closes the pull request and discards the work. The README acknowledges this and argues the trade-off: with knowledge of the test failures, the next attempt can try something different. The author connects this to a probabilistic view in which individual runs are not judged, only the general direction, and notes that if GitHub Actions kills the process after six hours you lose only dirty files that the next agent picks up.

The markdown file is the memory, and it is fragile

Context continuity is handled by a shared markdown file that acts as external memory. Claude records what it has done and what should be done next. The README is explicit that without prompting instructions the model would produce verbose logs that harm more than help, so the intent is a clean handoff package between runs. The key instruction quoted in the README tells the model this is part of a continuous development loop, that it does not need to complete the entire goal in one iteration, only make meaningful progress on one thing and leave clear notes for the next iteration, described as a relay race where you pass the baton.

The README gives one production example: an iteration ended with a note that it had tried adding tests to something, failed on an edge case, and needed to handle null input in a particular function, and the next invocation saw that and prioritized it. The author's claim is that a single small file reduces context drift, where the model forgets earlier reasoning and goes in circles. There is also a self-improvement story: a vague instruction such as increase coverage becomes, over iterations, run coverage, find files with low coverage, do one at a time.

I would treat the file as the weakest link rather than a solved problem. It is a single mutable artifact that the agent writes to and reads from, and nothing in the supplied material describes a schema, a size limit, or a conflict resolution rule when two runs touch it. The relay-race prompt is good practice, but it is a prompt, not a mechanism. If the notes drift, every later iteration inherits the drift. The README itself warns that verbose logs harm more than help, which is an admission that the file's quality is not guaranteed by the tooling.

Getting it running: the commands the material shows

The repository is a Shell project on the main branch, licensed MIT, and the README does not include an installation section in the supplied text. So I cannot give you a verified install command, and I will not invent one. What the README does show is the shape of the invocation. The original loop calls the claude binary directly with the flag --dangerously-skip-permissions and a quoted prompt, then sleeps for one second before repeating. The shipped script keeps that call and layers the git and GitHub steps on top.

The external dependencies are visible from the steps: the claude CLI, the git CLI, and GitHub's gh CLI, specifically gh pr checks for monitoring. The flag name is worth pausing on. --dangerously-skip-permissions is what lets an unattended loop edit files and run commands without stopping for approval, and it is the reason the author's framing of each run as roughly idempotent matters. If the process is killed, the next run picks up the dirty state. The prompt file convention shown in the README is TASKS.md for notes.

Because the loop drives GitHub rather than a local merge, your repository settings are part of the configuration surface. Branch protection, required status checks, and code owner review all apply, and the README presents that as a feature. The practical consequence is that you configure Continuous Claude partly by configuring GitHub: which checks must pass before the script's merge step can succeed, and whether a human review is required. If a human review is required, the loop will wait rather than merge, which changes the tool from autonomous to assisted.

Where the loop breaks down

The discard-on-failure behaviour is the most consequential limitation and the README states it directly: when an iteration fails, the script closes the pull request and discards the work. The author calls this wasteful. It is also expensive in a way that scales with how often your checks fail, and it means a task that needs twenty attempts to get one good commit pays for all twenty. The justification is that the next attempt learns from the failure, but that learning only survives if the failure information reaches the markdown file. If the agent's notes omit the reason a check failed, the next iteration starts from roughly the same place.

The second limitation is the permission flag. Running an agent with permissions skipped, in a loop, against a real repository is a broad grant. The README does not describe a sandbox, a filesystem boundary, or a review step before the commit is pushed. The mitigation it offers is architectural rather than preventive: work lands on a branch and must survive CI and any required review before merging. That is a reasonable gate, but it is a gate on the merged result, not on what the agent does while running.

The third is task fit. The loop assumes progress can be decomposed into independent small pull requests. A change that requires one coherent design decision across many files, or a task whose correctness cannot be expressed as a passing check, does not fit. The README's own examples, coverage, dependency breakage, mechanical refactors, all share the property that success is measurable by an existing test suite. Where that property is absent, the merge signal is meaningless and the loop is the wrong tool.

Continuous Claude against GitHub Next's agentics

The README points to GitHub Next's Continuous AI project and the agentics repository, and quotes Principal Researcher Don Syme on fault tolerance: if things go wrong the agent hits resource limits and tries again, or the user throws the generated pull request away, which he contrasts with a frustrated user guiding an agent down a wrong path. That is the same discard-the-PR philosophy, so the difference is not the failure model.

The difference is structure. The README describes agentics as combining an explicit research phase with pre-build steps that ensure the software is restored before agentic work begins. Continuous Claude has no equivalent phase in the material supplied. Its iteration is branch, prompt, commit, push, check, merge, and its only persistent artifact is the markdown notes file. So agentics front-loads context reconstruction on every run, while Continuous Claude relies on the relay-race prompt to carry context forward. The README also mentions a proposal from the GitHub Next team to run specialized agents simultaneously, one for development, one for tests, one for refactoring, and notes the coordination challenge that introduces; the author says he is trying a similar approach for tests in different parts of a monorepository. That is an experiment, not a documented feature, so I would not plan around it. The honest comparison is that agentics is a broader research effort with a defined pre-build phase, and Continuous Claude is a single Bash script with a narrow contract: one branch, one pull request, one merge decision per iteration.

Maintenance, releases and the MIT licence

The repository is not archived, the default branch is main, and the last push recorded is 2026-08-24. Releases are frequent and small: v0.24.6 and v0.24.7 both landed on 2026-05-09, and v0.24.8 on 2026-07-13. A version series in the point-two-fours with patch releases days apart suggests active iteration rather than a stable API, and because the project is a script, upgrading means replacing the script and re-reading its prompts rather than resolving a dependency graph. Your prompts and the markdown file are your own artifacts; the script is the author's. That split is the real upgrade cost. A change to the loop's prompt wording or to how it writes notes can alter agent behaviour without any change to your code.

The licence is MIT. That permits use, modification and redistribution with the licence and copyright notice retained, and it comes with no warranty. I am not a lawyer and this is not legal advice, but the practical implication for a team is that you can vendor the script, patch it, and keep your changes private. If you fork it, the maintenance burden shifts to you: the loop's behaviour lives in the prompts inside the script, so a fork drifts from upstream quickly. Check the licence file in the repository for the exact terms before redistributing.

Editorial conclusion

Adopt Continuous Claude when your repository already has CI checks and code review rules that can act as the gate, and when the job is a long grind such as raising coverage or a mechanical refactor that can be split into many small pull requests. Do not adopt it for a single feature or a fix you can describe in one prompt, because the loop's discard-and-retry behaviour spends tokens on work that gets thrown away. Before running it, confirm three things in your own repo: that gh is authenticated and can create and close pull requests, that your required checks reject bad commits without human intervention, and that the shared markdown file is committed somewhere the next iteration can read it. The tool is a Bash script under MIT, so the loop's value depends entirely on the quality of the checks you point it at.

Official sources

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