Run the review when nobody is watching

Before you trust a change to the payments service - the small TypeScript service this course uses as its running example - you run a pass by hand: npm test, read the diff, ask whether anything regressed. It works, and it only happens when you remember. This chapter takes that pass unattended, in two places:

• On every trusted, same-repository pull request, as a CI check - a headless Claude Code run (headless meaning no interactive interface: a script starts the agent, it does the work, prints its result, and exits) reviews the diff and comments before a human ever looks at it. Fork contributions need a separate workflow because GitHub withholds repository secrets from their ordinary pull_request jobs.
• Every night against main, as a scheduled job - the agent reruns the checks and reviews the tree for regressions, and a fresh issue is waiting for whoever is first online when it finds one.

In an interactive session, permissions are mostly a rhythm. The agent reaches past its rules, a prompt appears, you answer. Take the human out of the room and the prompt has nowhere to go. What you tuned in Permissions & modes - allow rules, deny rules, the mode dial (how much the agent may do before it has to ask) - stops being a convenience and becomes the entire safety story. Nothing ahead introduces a new safety model. The chapter removes the backstop and checks what holds.

The pass has to review, not merely run

One fact about the repo shapes both designs. The suite is green today - six tests, six passing - while known defects are still in the code: a race in allowAsync (src/payments/rate-limiter.ts, where a read and a write sit across an await, so two callers can both pass the limit check) and a zero-balance reporting bug (the subagents chapter traces how the second one was run down). The tests catch neither. A job that only runs npm test would sleep as soundly as the tests do. The automated pass has to review, not merely run: the checks are one input to its verdict, not the verdict.

The trick the whole chapter circles: non-interactive means no human to approve prompts, so the run either holds permission for what it needs in advance, or it hits a wall you did not mean to build. Getting that pre-grant generous enough to finish the job and tight enough to contain a hijacked run is the real skill of running unattended. And the failure mode when you get it wrong is stranger than a crash - which is why the permissions lesson comes before the CI one:

• Run Claude Code headless with the -p flag - drive the agent from a script, pipe the diff in, read the verdict back as text or JSON
• Make permissions hold when no one is there to approve - what actually happens to a denied call in -p, and the three-layer posture that refuses by default
• Run the review on trusted pull requests with GitHub Actions - the action, its credential paths, the fork boundary, and a workflow whose permissions are actually correct
• Build the nightly regression loop and fence it in - compose the headless call into a scheduled job, with the guardrails that keep an unwatched run honest

This is the course’s control principle - what guides execution, enforces boundaries, or lets you intervene - at its widest reach. Removing yourself is justified exactly while the run stays verifiable and reversible: success checkable by evidence the run had to produce, errors recoverable because its reach is small. Every job ahead is built that way on purpose. By the end, the review runs in two places without you, and you can say where the line sits between delegating a task to an agent and abandoning one.

Start with the headless flag.