Why overnight

A fleet working while the plant team sleeps turns fourteen idle hours into build time, and you spend your working day doing what only you can do: deciding, reviewing and talking to the floor. The price is that nobody is watching. Everything in this element exists to make an unwatched night safe and its results easy to check in the morning ^[1].

The night plan

Write the night on one page in your repository, docs/nights/YYYY-MM-DD.md, so the plan is versioned with the code it produced. Session 15's wave plan supplies most of it.

Where the fleet runs

The four guardrails

1. Permissions: dontAsk with an exact allowlist

Unattended runs cannot answer permission prompts, so decide in advance. Claude Code's dontAsk mode allows only reads and the tools you pre-approve, and denies everything else instead of asking. Deny rules apply in every mode ^[5][6]. The mode that skips all checks is meant only for isolated containers and virtual machines; never use it on a machine that holds keys or company files ^[5].

{
  "permissions": {
    "defaultMode": "dontAsk",
    "allow": [
      "Read", "Edit",
      "Bash(npm test *)", "Bash(npm run lint *)",
      "Bash(git status)", "Bash(git diff *)", "Bash(git add *)", "Bash(git commit *)", "Bash(git push origin wave2/*)"
    ],
    "deny": [
      "Read(./.env*)", "Bash(git push --force *)", "Bash(npm install *)", "Bash(curl *)", "Edit(./test/acceptance/**)", "Edit(./package.json)"
    ]
  }
}

2. Sandbox: the worktree and listed hosts only

Claude Code's sandbox runs the agent's shell commands inside a boundary: writes are limited to the working folder, and network traffic goes through a proxy that allows only the hosts you list ^[7]. Turn it on for unattended work, and list only what the tests need (for example the npm registry if packages are restored, and nothing else).

3. Branch protection: pull requests only

Session 1 protected main: changes arrive by pull request, CI must pass, nobody force-pushes ^[8]. That is what makes a night recoverable. The worst a worker can do is open a bad pull request, which you close in the morning.

4. Spend caps

Every run gets --max-budget-usd and --max-turns; the fleet's API workspace gets a monthly spend limit (Session 15) ^[2]. Add the caps together before you leave: the most the night can cost is the sum of the per-run budgets, and you should be comfortable with that number.

The dry run

Thirty minutes before you leave, start every worker with a budget of one dollar. Watch the first few minutes: does each one find its brief, run its tests, commit and push to its own branch? Do the deny rules hold (try asking one to read .env)? Then stop them, delete the dry-run branches, and start the night for real, a minute or two apart.

# Start the night: one bounded headless worker per worktree, staggered. Run from the folder that holds the worktrees.
for N in 2 3 4 5; do
  ( cd agent-$N && claude -p "$(cat ../platform/briefs/agent-$N.md)" \
      --permission-mode dontAsk --max-budget-usd 8 --max-turns 80 \
      --output-format json > ../logs/agent-$N.json 2> ../logs/agent-$N.err ) &
  sleep 120
done
wait; echo "Night finished: $(date)"

A worker's night

Each worker starts queued, then works in a loop: change some code, run its tests, fix, commit, push. It ends in one of two ways: it opens a pull request because its acceptance tests pass, or it stops because a rule told it to. Either way it writes down why.

Stop rules

A worker left to itself will keep trying, and every try costs money. Write the rules that end a run into the brief, and back the important ones with hard limits outside the agent:

A heartbeat you can read

Each push to a worker's branch is a heartbeat. Pushing small commits also means a restart loses minutes, not hours. In the morning, the pattern of pushes tells you at a glance which worker kept going, which finished early and which went quiet.

You can collect richer signals too. Claude Code can export usage and cost metrics through OpenTelemetry to a monitoring tool you already run, and hooks can run your own script when a session stops or needs attention, for example to append a line to a log ^[3][4]. Keep it simple at first: pushes, the JSON result of each run (which includes its cost) and the workers' notes are enough ^[5].

Who gets woken up?

Nobody, if the guardrails are right. Site reliability engineers have a useful rule: alert a person only for something that needs a person now ^[6]. An overnight build has nothing like that: it cannot touch production, cannot merge and cannot spend past its caps. A worker that stops simply waits for the morning. If you find yourself wanting an alert, a guardrail is missing; add it instead.

When something breaks

• The machine restarted. Everything up to the last push is safe on the branch. In the morning, start a fresh run in the same worktree with the same brief plus one line: continue from the commits already on this branch.
• The rate limit was hit. Workers slow down or pause and retry. Stagger the starts more next time, or run fewer workers at once ^[7].
• The cache went cold. A worker that waited a long time pays more for its next request. That is expected; it is not worth waking up for.
• A worker finished early. Good. Do not hand it new work at night: unplanned work is unreviewed work.

Cheapest check first

Do not start by reading the biggest pull request. Run every pull request through checks in order of cost: the automatic ones first, your careful reading last. A pull request that fails an early check goes back without you spending time reading it.

Reading the change

Every change that reaches the plant's platform is read by a person. Google's code review guide puts the reviewer's job simply: approve once the change clearly improves the health of the code, even if it is not perfect, and look at design, function, complexity, tests, naming and comments ^[4]. For agent work, add the spine's rules:

Merging in sequence

Each merge changes main, so a pull request that passed CI last night may not pass against this morning's main. Merge one at a time, in the order of the wave plan: rebase the next pull request on the new main, let CI run again, then merge ^[6]. GitHub's merge queue automates the same discipline when many pull requests land at once ^[7].

# Merge the next pull request in sequence (its branch: wave2/agent-3). Run in your main clone.
git fetch origin
git switch wave2/agent-3 && git rebase origin/main     # stop here if there are conflicts
npm ci && npm test                                     # the same checks CI will run
git push --force-with-lease origin wave2/agent-3      # updates the pull request; CI runs again
# When CI is green on GitHub, merge the pull request there (squash) and delete the branch.

Every failure improves the next night

A pull request you send back is information. Most failures trace to the brief: a missing file path, an acceptance test that did not pin the behaviour, a limit that was not stated. Rewrite the brief and keep both versions: Session 16's homework (assignment 4) asks for a brief you rewrote after a bad result, and why.

Close the night

1. Write one line per worker in the fleet ledger: model, turns, cost, merged or not, review minutes (Session 15).
2. Add up the cost per merged change and compare it with last night.
3. Delete merged branches and worktrees you no longer need: git worktree remove ../agent-3.
4. Write the next night's plan while the lessons are fresh.