Anthropic's early-July 2026 Claude Code release (v2.1.200) makes two changes that look small in a changelog but reshape how teams should run coding agents. First, AskUserQuestion dialogs no longer auto-continue by default — the agent waits for a human answer instead of picking one and moving on. Second, the permission mode formerly labeled "default" is now called "Manual" across the CLI, the VS Code extension, and the JetBrains plugin. Alongside these, Anthropic has been rolling out checkpoints for autonomous development.
On the surface these read as friction. In practice they are the guardrails that make longer autonomous runs safe enough to trust. The interesting question isn't "how autonomous can the agent be" — it's "how cheaply can I undo a bad decision." Checkpoints answer that.
What Checkpoints Actually Give You
A checkpoint is a restorable snapshot of the working state the agent captures before it starts a meaningful unit of work. If the agent takes three steps down the wrong path — refactors a module in a way that breaks a contract, edits the wrong file, misreads a failing test — you rewind to the checkpoint instead of manually reverting a tangle of edits.
This changes the economics of autonomy. Previously, the cost of an agent mistake was proportional to how far it wandered before you noticed. With checkpoints, the cost is bounded by the distance to the last snapshot. That's the difference between "I have to read every diff before I trust this" and "let it run, I can roll back a bad segment in seconds."
Checkpoints are not a replacement for Git. Git is your durable, reviewable history; checkpoints are ephemeral in-session safety for the agent's own exploration. Use both:
# Durable boundary: commit before handing a task to the agent
git add -A && git commit -m "checkpoint: before dependency upgrade"
# The agent creates in-session checkpoints as it works.
# If a segment goes wrong, rewind to the agent checkpoint —
# not all the way back to the git commit.Why "Manual" as the Default Name Matters
Renaming the default permission mode to "Manual" is a signal, not just a label. It tells operators plainly: out of the box, the agent asks before acting. Autonomy is something you opt into deliberately, per project, not something you inherit silently.
We think this is the right default. The failure mode we see most often when teams adopt coding agents is jumping straight to full autonomy on a repository that has no test coverage, no clear permission boundaries, and no rollback rehearsal. The agent does something plausible-looking, it lands in a place nobody reviewed, and the team loses trust in the tool for months.
A useful mental model is three tiers, which you can encode in settings.json:
{
"permissions": {
"mode": "manual",
"allow": [
"Bash(npm run test:*)",
"Bash(npm run lint)",
"Bash(git diff:*)",
"Bash(git log:*)"
],
"deny": [
"Bash(rm -rf:*)",
"Bash(git push --force:*)",
"Bash(curl:*)"
]
}
}Read-only and idempotent commands go in allow so the agent doesn't interrupt you to run tests. Destructive or outbound commands go in deny. Everything else falls through to a manual prompt. The AskUserQuestion change reinforces this: when the agent hits a genuine decision point, it stops and asks rather than guessing.
A Rollback-First Autonomy Loop
The pattern we recommend to clients treats checkpoints and commits as the backbone of the loop, not an afterthought:
- Commit a clean baseline. The agent should always start from a state you could ship.
- Scope the task narrowly. "Refactor the error handling in this one module and keep the existing tests green" beats "improve error handling." Narrow scope means a nearby checkpoint to rewind to.
- Let the agent checkpoint as it works. Each sub-step becomes a rewind point.
- Gate the outcome on tests, not on vibes. The loop is only "done" when the test suite passes — a signal the agent can verify without you.
- Review the final diff, not every keystroke. With a passing suite and a clean baseline, you review one coherent change instead of watching a live stream.
# A shape that works well for unattended-but-bounded runs
git commit -am "baseline: feature branch clean"
claude --permission-mode manual \
"Refactor the retry logic in src/lib/http.ts to use exponential
backoff. Keep all existing tests passing. Do not change the
public function signatures."
# Agent works, checkpointing between steps.
# On success: review one diff. On failure: rewind and re-scope.
npm run test && git diffThe constraint "do not change the public function signatures" is doing real work here. Explicit boundaries in the prompt are cheaper than permission config for task-specific limits, and they give the agent a clear failure condition.
Where Autonomy Still Breaks Down
Checkpoints make mistakes cheap to undo, but they don't make the agent's judgment sound. These remain human calls:
- Decisions with business context. Whether a feature should exist, which of two valid behaviors is correct, how to prioritize competing constraints.
- Irreversible side effects. Anything that leaves the local workspace — sending email, mutating production data, publishing a package. A checkpoint can't rewind a sent request.
- Silent scope creep. An agent asked to fix a bug may "helpfully" refactor adjacent code. Narrow prompts and tight
denylists keep this in check.
The AskUserQuestion-waits-by-default change directly targets the first category: at genuine forks, the agent now pauses for a human rather than committing to a plausible guess.
Our Take
The framing that matters is not "agents are getting more autonomous" but "the tooling around agents is getting better at making autonomy reversible and auditable." Checkpoints, a Manual default, and blocking question dialogs all push in the same direction: let the agent move fast within a bounded, recoverable space.
For teams starting now, we suggest three things. Keep the Manual default and expand the allow list gradually as you build confidence. Commit a clean baseline before every agent task so checkpoints have somewhere to fall back to. And rehearse your rollback once, deliberately, before you rely on it — an untested recovery path is not a recovery path. Get those three right and autonomous coding stops being a leap of faith and becomes a normal, boring part of the workflow, which is exactly where you want it.