Running Claude Code headlessly in CI or in the background removes the live approval step from Module 1's loop — which makes defining its scope and permissions upfront more important, not less.
1CI and Background Runs Remove the Live Approval Step
A headless CI job or a long-running background task can't pause for you to approve each risky action the way an interactive session does. That doesn't remove the need for the permission discipline from Module 1 — it moves that decision earlier, into how the run is configured before it ever starts.
2Safety Has to Be Designed In, Not Approved In the Moment
A CI review job should be scoped to exactly what it needs — reading a diff, posting a comment — and explicitly denied anything with broader consequence: pushing commits, merging, running arbitrary shell commands. Tight upfront scoping is what makes an unattended run trustworthy.
3Step-by-Step Breakdown
Beyond a Session You're Watching. Everything so far has been an interactive session, with you approving each risky step. Claude Code can also run headlessly in CI — reviewing a pull request automatically on every push — or in the background on a longer task, like triaging a batch of open issues, without a human watching every action live.
A CI Check on Fixly's Pull Requests. A GitHub Actions workflow can run Claude Code on every PR to Fixly, checking the diff against the same standards from Module 3 and Module 5 — reuse, scope, real test assertions, and security — and posting findings as a comment, without a human having to kick it off manually each time.
In a headless CI run with no human approving each step live, what still needs to be true for it to be used safely?
- →Its permissions and scope need to be defined tightly in advance — e.g. read-only or comment-only access — since there's no live approval step to catch an unsafe action in the moment.
- →Nothing changes; the same open-ended permissions from an interactive session are fine unattended.
Scope a Headless Run's Permissions. Design what a CI review run should and shouldn't be allowed to do, given there's no human approving each action live.
The Discipline Doesn't Go Away Unattended. Whether it's you approving a step live, or a CI job scoped tightly in advance, the same idea holds from Module 1 through here: real access is powerful, and powerful things get bounded and checked, never assumed safe. You've now taken Fixly from a failing test to a shipped, reviewed, security-checked feature with automated review in place — the same workflow, end to end, that a careful engineering team actually runs. One bonus lesson closes things out: everyday tips and tricks.
Level Up 🚀
Advanced cheat sheets, SEO tricks, and interview prep for this topic.
Browser Support
N/A — CI and background runs execute in a pipeline or terminal, not a browser.
N/A — CI and background runs execute in a pipeline or terminal, not a browser.
N/A — CI and background runs execute in a pipeline or terminal, not a browser.
N/A — CI and background runs execute in a pipeline or terminal, not a browser.
Accessibility (A11y)
1Post Automated Findings as Plain, Scannable Comments
A CI review's output, like every other Claude Code interface in this masterclass, works best as clear, structured plain text — readable the same way by any reviewer or accessibility tooling regardless of how the finding was generated.
SEO Implications
- 1
Target 'Claude Code in CI/CD' and 'running Claude Code unattended safely' separately
Teams search for the specific integration pattern and for the safety question of unattended operation as related but distinct concerns.
Best Practices
Scope Unattended Runs to the Narrowest Permissions the Task Actually Needs
A read-and-comment CI review job never needs push, merge, or arbitrary shell access — granting only what the specific unattended task requires keeps the absence of live approval from becoming a real risk.
Frequent Bugs
Configuring a headless or background run with the same broad permissions used in an interactive, human-approved session.
Define the run's scope narrowly upfront — exactly the actions the unattended task needs, nothing more — since there's no live approval step to catch an overreach in the moment.
Real-World Examples
The Over-Permissioned CI Job
An early draft of Fixly's PR-review workflow gave the CI job the same broad permissions as an interactive session, including the ability to push commits. Scoping it down to read-diff-and-comment-only removed that risk entirely, without reducing its usefulness as an automated first-pass reviewer.
// Over-permissioned: could push commits, unattended
// Scoped: read diff, post comment -- nothing else