You open a pull request before a meeting. Forty minutes later, a check goes red on a test you didn't even touch. You don't see it until you're back — and by then the failure has gone cold. You're re-reading a stack trace you should have caught the moment it happened, trying to remember what you were mid-thought about before the meeting pulled you away. Multiply that by every PR your team opens in a week, plus the small review comments that need the same context switch to fix, and "waiting on CI" quietly becomes one of the most expensive things an engineer does.
Why the build stayed red until standup
Fixing it yourself meant being the one watching. Notice the failure, read the log, decide what broke, write the fix, push, wait for the checks to run again. Asking an AI assistant for help didn't remove that loop — it just moved one step of it into a chat window: copy the error, paste it in, wait for a reply, review, push it yourself. Every step still needed you to be present and paying attention at the exact moment the build turned red, which is precisely the moment you're usually not.
What auto-fix actually does
Claude Code on the web can watch a pull request and react to it on its own. Turn it on for a PR, and Claude subscribes to that PR's GitHub activity. When a check fails or a reviewer leaves a comment, Claude investigates without anyone telling it to, and pushes a fix if it's confident in one. You stop being the trigger. It's currently a research preview, included at no extra charge on the Pro, Max and Team plans and for Enterprise seats with Claude Code access — so a freelancer on the $20-a-month Pro plan gets the same auto-fix as a funded engineering team, not a feature gated behind an enterprise contract.
Turn it on for a PR you already opened
- In Claude Code on the web (claude.ai/code), open the PR's CI status bar and switch on Auto-fix.
- From your terminal, check out the PR's branch and run /autofix-pr — Claude Code finds the open PR itself and starts watching, no web session to open by hand.
- From the mobile app, just say "watch this PR and fix any CI failures or review comments."
- On any existing PR — including one you wrote by hand with no AI involved — paste the PR URL into a session and tell Claude to auto-fix it.
git checkout add-refund-endpoint
gh pr view --json number,url # confirm the PR is open
claude
> /autofix-prThat's the entire setup. No workflow file, no secret to add — auto-fix rides on the Claude GitHub App you install once, and from that point it's a per-PR toggle rather than something you configure per repository.
What happens after that
Every event on the PR gets a decision, not a reflex. A clear fix — a broken import, a test that needs updating for a signature change, a straightforward lint failure — gets made, pushed, and explained in the session. Anything ambiguous, or anything that touches something architecturally significant, gets asked to you instead of guessed at. An event that's a duplicate, or genuinely needs no change, gets logged and quietly skipped. You still open the diff and hit merge yourself; auto-fix pushes commits, it doesn't approve them.
Auto-fix doesn't decide what's safe to ship. It decides what's safe to try — and the gap between those two is exactly why it asks before touching anything it isn't sure about.
Common mistake
Claude's replies to review comments post under your own GitHub account, labeled as written by the agent — but if your repository runs comment-triggered automation like Atlantis, Terraform Cloud, or a custom Action listening on issue_comment, that reply can trigger it. Audit what fires on a PR comment before you turn auto-fix on for that repository, especially anywhere a comment can kick off a deploy.
Where it's the wrong tool
Skip it when the base branch moves and creates a merge conflict — GitHub doesn't send a webhook for that, so auto-fix has no event to react to and the PR just sits there until you notice and ask Claude to rebase. Skip it for a two-line fix you're already staring at; turning on a watcher for something you're about to push yourself is overhead, not help. And skip it, or scope it carefully, on any repository where a PR comment can deploy infrastructure — that's the one place the convenience becomes a real risk rather than a saved context switch.
None of this replaces the judgment call on whether a change should ship — that's still yours, every time. What it removes is the tax of being the one who has to notice the build went red in the first place, and the twenty minutes of re-loading context that follows once you finally do. For a solo freelancer, that's fewer evenings spent reopening a PR to see what broke. For a team, it's fewer pull requests sitting red for an entire day because whoever opened it went into back-to-back meetings.
Deciding which of your team's repositories are safe to hand a permanent watcher, and which need the Terraform or Atlantis conversation first, is exactly the kind of scoping we walk through in an AI Opportunity Assessment.