01
What changed in v2.1.198 — read this first
Claude Code v2.1.198 changed how background agents launched from
claude agents finish their work. Before, an agent that finished coding in a worktree would stop and ask you what to do next. Now it does the last mile on its own. Straight from the v2.1.198 release notes: "Background agents launched from claude agents now commit, push, and open a draft PR when they finish code work in a worktree, instead of stopping to ask."- The agent commits its work — a real git commit, unattended.
- It pushes that commit to your remote.
- It opens a draft PR — so the code is on GitHub before you've looked at a single line.
This is a productivity win, not a scare story: the agent gets the boring plumbing out of the way. But it's a behaviour change, and if you deploy an agent on autopilot without knowing it, code you never reviewed lands on your remote. Know it before you deploy.
02
The companion change: an agent's message is not your approval
The same release tightened how subagents read instructions — a quiet but important guardrail. From the release notes: "Subagents now treat messages from the agent that launched them as normal task direction; an agent's message is still never treated as the user's approval."
- A subagent will follow a parent agent's direction as a task to do.
- But it will never read that parent agent's message as if you had approved something.
- Net effect: approval still has to come from a human. One agent can't manufacture consent for another.
Good to know when you're chaining agents: the auto-commit behaviour above is the thing you contain, and this guardrail is why real approvals still route back to you.
03
The containment lever: one deny rule
Here's the reassuring part. Claude Code reads a permissions block from your settings, and a deny rule always wins — it blocks a command outright, no prompt, no override. That's not new in v2.1.198; it's the standard permission model. Point it at
git push and the agent physically cannot push or open a PR — it'll do its work and commit locally in the worktree, then stop. Add this to your settings.json:{
"permissions": {
"deny": [
"Bash(git push:*)"
]
}
}Read it as:
permissions → deny → Bash(git push:). The : matches git push with any arguments. Because it's a deny rule, it takes priority over anything in allow — the agent's push is stopped before it runs, and with nothing pushed there's no draft PR either.04
Choose your containment level
Match the deny rules to how much rope you want to give the agent. Pick a row and paste those into
permissions.deny:| You want | Deny rule(s) to add | What the agent can still do |
|---|---|---|
| Nothing leaves your machine unreviewed | Bash(git push:*) | Work, then commit locally in the worktree — you push |
| No commits either (fully hands-off review) | Bash(git commit:), Bash(git push:) | Make the file changes; you stage, commit and push |
| No PR opened even if pushed elsewhere | Bash(git push:), Bash(gh pr create:) | Everything up to the remote; PR stays yours to open |
Start with just
Bash(git push:*) if you're unsure — it's the single highest-impact line. It keeps the auto-commit convenience (fast local checkpoints) while making sure nothing reaches your remote until you say so.05
The 3-step pre-deploy checklist
Run this once before your next background-agent deploy. Two minutes, and you deploy knowing exactly what your agents can and can't do:
- Read the v2.1.198 release note. Confirm you're on v2.1.198 or later and that you understand the new finish-the-work-and-open-a-draft-PR behaviour. If you didn't know it until now, that's the whole point of this step.
- Add the deny rule. Open your
settings.jsonand addBash(git push:*)underpermissions.deny(plus any rows from the table above that fit your risk appetite). A deny rule is absolute — the push simply can't run. - Make reviewing draft PRs a habit. The design is sound: the agent opens the draft, you still merge. So build the muscle — check the draft PR, read the diff, and only then click merge. Autonomy on the work, a human on the gate.
Honest framing: this is operator safety — know before you deploy — not fear-mongering, and not a knock on the tool. The auto-commit change is genuinely useful; the deny rule and the review habit just keep you in control of what ships.
Get the next drop
One AI operator-safety habit a week, plus the occasional bonus template. No spam, unsubscribe anytime.
By submitting you agree to our Privacy Policy & Terms. Unsubscribe anytime.
You're in — check your inbox to confirm.
Frequently asked questions
What exactly changed in Claude Code v2.1.198 for background agents?
Background agents launched from
claude agents now commit, push, and open a draft PR when they finish code work in a worktree, instead of stopping to ask. It's the last-mile plumbing done automatically — which is convenient, but means unreviewed code can reach your remote if you deploy an agent unattended without knowing this.How do I stop a Claude Code agent from pushing code?
Add a deny rule to your
settings.json permissions: deny Bash(git push:*). A deny rule is absolute — it takes priority over any allow rule, so the agent physically cannot run git push. With nothing pushed, no draft PR is opened either. The agent still does its work and can commit locally in the worktree.Is this a new setting introduced in v2.1.198?
No. The
permissions.deny mechanism is the standard Claude Code permission model, not new in v2.1.198. What's new in v2.1.198 is the auto-commit/push/draft-PR behaviour of background agents. The deny rule is simply the existing lever you use to contain that new behaviour.Does denying git push break the agent?
No. The agent still makes all its file changes and (unless you also deny
git commit) commits them locally in its worktree. It just can't send anything to your remote. You review the local work — or the draft PR if you allow pushing — and you do the merge.Should I be worried about this change?
Not worried — informed. The auto-commit/draft-PR flow is a genuine productivity gain, and the design keeps a human on the merge. This checklist is about knowing the behaviour before you deploy and setting one deny rule if you'd rather nothing reaches your remote unreviewed. Operator safety, not alarm.