Skip to main content

The Overnight Coding Loop

info

This content was developed with AI assistance and is regularly reviewed for accuracy.

Snapshot: October 2026. Model names, prices, and product features change monthly; What's New in AI is the maintained chronology.

This recipe builds your first real loop: a system that picks up a queued coding task, has an agent implement and test it, and leaves a pull request for you to review while you sleep. It is the canonical loop because the work is repetitive, the result is verifiable (tests pass or they do not), and the risky step, merging, stays with you. The 2026 version runs as a cloud Routine with your laptop closed, uses /goal as its completion check, and enforces its budget at runtime.

Last tested with Claude Code (Routines, /goal, and headless claude -p) in October 2026.

What you'll accomplish​

  • Queue work the agent may pick up on its own
  • Brief the agent through implement, test, and pull request on each task
  • Contain and verify so mistakes stay on a branch and CI, not the agent, decides success
  • Bound the loop with runtime budget, failure, and scope stop conditions
  • Keep the merge as your morning checkpoint

Prerequisites​

  • Claude Code on a paid plan with Routines available (Routines were a research preview on Pro, Max, Team, and Enterprise as of October 2026), and the GitHub connector
  • A git repository with a working test suite, CI on pull requests, and branch protection you can configure
  • Anatomy of an Agent Loop and Loop Guardrails and Safety read first
  • 60 to 90 minutes to set up and watch the first run

Step 1: Build the task queue​

Goal: Give the loop a defined list of work it is allowed to do unattended.

Action: Use GitHub issues with a dedicated label such as agent-ready. Each issue should be narrow, self-contained, and have an obvious "done." Good overnight tasks are small, verifiable, and low-stakes.

✅ Good: "Add input validation to the signup form; cover empty and malformed
         email with tests."
✅ Good: "Raise test coverage of utils/date.ts to 90%."
❌ Bad:  "Redesign the auth system." (too big, hard to verify, high-stakes)

Only people you trust should be able to apply the label, because whatever is in an issue body becomes input to the agent. Treat issue text as untrusted: a malicious issue is a prompt-injection route.

Checkpoint: You have two or three labeled issues you would hand to a new teammate with no supervision.

Step 2: Write the run brief​

Goal: Define exactly what the agent does each run, and where it stops.

Action: Write the brief the Routine will send. Name the queue, the sequence, the checks, the limits, and the stopping point.

Work the queue of open GitHub issues labeled agent-ready in [repo],
oldest first, at most 3 issues this run.

For each issue:
1. Create a branch named agent/[issue-number].
2. Implement only what the issue describes. Do not edit files outside its scope;
   if the fix needs that, stop and comment on the issue instead.
3. Run the full test suite, the linter, and the type checker. Fix what fails.
4. Open a pull request that links the issue. Do NOT merge.
5. Comment on the pull request: what changed, why, and anything uncertain.

If the same check fails twice on one issue, stop work on it, comment on the
issue with what you tried, and move to the next.
Finish by appending a summary of every issue to agent-log.md on the
agent/log branch.

The "Do NOT merge" line is your human checkpoint in writing. The log file is the loop's memory, and the next run reads it before starting.

Checkpoint: The brief names the branch, the work, the checks, the limits, and the stop (a pull request, not a merge).

Step 3: Contain it​

Goal: Make sure the worst plausible run is cheap.

Action: Set up the environment so the loop cannot reach what it should not, before you trust the brief to keep it in line.

  • Turn on branch protection for main: required CI checks and a required human review.
  • Give the Routine the GitHub connector for this one repository and remove every other connector. Routines include your attached connectors by default, and can use any tool on them, including writes, without asking.
  • Add deny rules in Claude Code's permission settings for destructive commands, and keep secrets out of the repository and any file the agent can read.

Checkpoint: Even if the agent ignored its brief, it could not merge, deploy, or reach another system.

Step 4: Put the evaluation outside the agent​

Goal: Let the system, not the agent, decide whether a task succeeded.

Action: A task counts as done only when CI is green on the pull request. When you run the brief in a session, set that as a /goal, so the agent keeps working until the condition holds, checked by a separate model after each turn:

/goal "CI passes on the pull request for this issue and no files outside its scope changed"

/goal reports the condition as not yet met, met, or impossible, and stops after several turns without progress. In the scheduled version, put the same sentence at the top of the brief as the definition of done, and keep CI as the gate either way. If your organization has Claude Code's Code Review (generally available for Team and Enterprise since October 15, 2026), let it review each pull request too, so you wake up to a second opinion as well as green CI. Never let the agent's own summary be the only evidence that tests passed.

Checkpoint: Completion is verified by CI and an independent check, not self-reported.

Step 5: Set the stop conditions​

Goal: Guarantee the loop ends, on success, cost, failure, or scope.

Action: Write the stop conditions before the first run, and keep them tight.

ConditionExample
SuccessNo agent-ready issues left, or 3 issues done this run
BudgetA runtime ceiling such as --max-budget-usd 5 on test runs, plus your plan's usage limits on the Routine
FailureThe same check fails twice on one issue: comment and move on
No progressIn a session, /goal reports no progress or "impossible": stop that issue
ScopeAny edit outside the issue's scope: stop and comment instead

Checkpoint: Every way the loop could run forever has a brake the runtime enforces.

Step 6: Watch one run, attended​

Goal: See the full loop behave before you trust it overnight.

Action: Run the brief once while you watch, with one issue in the queue and a low budget. A headless run from your terminal works well:

claude -p "[your run brief, limited to 1 issue]" --max-budget-usd 2

Confirm it picks the right issue, branches correctly, runs the checks, opens a pull request, and stops at the merge. Read the diff, the comment, and the log entry. If it touched extra files, marked a flaky test as passing, or looped on one issue, fix the brief or the containment before going further.

Checkpoint: One complete iteration, end to end, produced a pull request you would accept.

Step 7: Schedule it and review in the morning​

Goal: Run unattended, and make the merge your morning routine.

Action: Create a Routine with the run brief, the single GitHub connector, and a schedule such as 01:00 on weekdays (Routines run hourly at most). Alternatively, trigger it on a GitHub event, such as the agent-ready label being added, so work starts when it is queued.

Choose the right primitive. A Routine runs in the cloud with your laptop closed. /loop re-runs a prompt only while your session lives and expires after seven days, which suits babysitting a pull request during the day, not overnight work. Desktop scheduled tasks sit in between.

In the morning, review each pull request like any other. Check the run's result, not just its status, because a green run list does not mean the brief succeeded. As trust grows over many runs, widen the budget, add task types, or allow auto-merge for the lowest-risk changes, such as dependency bumps with full test coverage. Earn that autonomy; do not start with it.

Checkpoint: The loop ran alone, stopped at its limits, and left reviewable pull requests.

Troubleshooting​

  • It picks tasks that are too big. Tighten the label rules and split epics before labeling. "Overnight" means several small tasks, not one giant one.
  • It claims tests passed that did not. Check that completion depends on CI status, not the agent's comment, and that /goal names CI.
  • Costs are higher than expected. Check /usage to see which part of the run is expensive; route verbose test output to a subagent, and keep to one agent rather than a team.
  • It wanders outside scope. Restate the scope rule in the brief and add deny rules for the paths it should never touch.

Key takeaways​

  • The loop works because tasks are small, results are verifiable, and merging stays human
  • Run it as a cloud Routine with one connector; use /loop only for session-length jobs
  • Contain first: branch protection, a single scoped connector, deny rules, no secrets in reach
  • Let CI and /goal decide success, and enforce budgets at runtime
  • Watch one attended run, then widen autonomy only as the loop earns it

Next steps​

Continue to: The Research and Monitoring Loop for a loop that does not write code.

SponsoredYour product hereReach people actively learning AI — flat monthly rates, no ad networks