AI
Anthropic says auto mode catches 89% of dangerous commands against 13.6% for human reviewers, and still calls it not risk-free. The config, hooks, and review habits that keep it honest.
On this page #
how to use AI series #
- 1 AI Code Hallucinations: When Your AI Writes Confident Nonsense - 2 We Became Editors-in-Chief, and Nobody Trained Us - 3 Claude Code Auto Mode: What Still Needs a Human
Starting August 14, auto mode becomes the default permission mode for Claude Code on Pro, Max, and Team plans. Buried in Anthropic’s own announcement is a number worth sitting with: in a controlled test with 1,053 paid professional testers, researchers swapped in genuinely dangerous commands partway through real sessions. Humans caught 13.6% of them. Auto mode’s classifier caught 89%.
That’s not a subtle gap, and reading it made me a little uncomfortable, because I’ve spent most of the last few months running my own sessions in accept-edits or auto mode, clicking through permission prompts the same way everyone apparently does. Anthropic’s own usage data backs that up: people approve 97% of ordinary permission prompts, and the rate at which someone actually catches a dangerous one degrades from roughly 17% early in a session to about 5% after fifty-plus prior approvals. We’re not reading carefully. We’re pattern-matching on “this looks like the last forty things I clicked yes on,” and that pattern breaks exactly when it stops holding.
| Human review | Auto mode classifier | |
|---|---|---|
| Dangerous commands caught (1,053-tester study) | 13.6% | 89% |
| Production-severity unintended harm, real flagged sessions | 6.3% | 2.4% |
The second row comes from Anthropic’s audit of real, already-flagged sessions rather than a lab test: manually-approved sessions contained serious unintended harm more than twice as often as auto mode sessions did. Different methodology, same direction.
What actually changes on August 14 #
Auto mode itself is a fairly simple change to the default flow. Right now, Claude s before most file edits and shell commands and waits for you to click approve. Under auto mode, it doesn’t. Instead, a separate classifier model reviews each action in the background as Claude proposes it, and only interrupts you when it judges something risky: an irreversible action, a request that escalates beyond what you asked for, an attempt to send data somewhere it shouldn’t go. Everything else, the reads, the routine edits, the ordinary shell commands, runs without a prompt at all.
The classifier sits underneath the permission mode you’ve already picked, not instead of it. Your allow, ask, and deny rules resolve first; the classifier only gets a say on whatever those rules don’t already settle. That layering is exactly what makes the rest of this post possible: the classifier isn’t the only thing standing between Claude and a bad command, it’s the last one, and everything upstream of it is something you configure.
The asterisk Anthropic puts on its own number #
None of this means auto mode is safe, and Anthropic doesn’t claim it is. Their own line: “auto mode relies on classification systems and therefore does not eliminate risk.” They ran a two-week red-teaming pilot with Apollo Research, injecting synthetic attacks into real workflows. Before the hardening that shipped with this release, the classifier missed 12% of those attacks. After hardening, 7%, on a test set the classifier had never seen during tuning. Better than a distracted human. Not zero.
What the classifier is actually built to catch is specific: scope escalation on a vague or destructive request, credential exploration, exfiltration through an external service like a public gist, retrying a failed deploy with a skip-verification flag, a command that reads normally but was seeded by hostile content Claude picked up along the way. Where it still misses isn’t usually “is this dangerous”, it correctly flags danger most of the time. It’s “does a real consent signal in this session actually cover this specific action”, the same ambiguity a tired human glosses over, just less often.
So the useful question isn’t auto mode versus manual review. It’s what to put alongside auto mode that fails in a different way than auto mode does.
Rules that hold no matter the mode #
The classifier isn’t the only layer available, and it’s not the one you have the most control over. Permission rules sit underneath it: the docs are explicit that “these controls apply in every mode, including bypassPermissions
: deny rules and explicit ask rules.” Deny is a hard stop the classifier never gets to weigh in on. Ask still forces a prompt, even in a mode whose entire point is skipping prompts, which matters because the example below relies on it.
Here’s a concrete gap worth knowing about: auto mode auto-approves pushes to any branch of the repository you’re working in, including the default branch, unless you tell it otherwise. The classifier judges the push’s content on its own terms, but the act of pushing to main
isn’t itself something it blocks by default. If you want that to always stop for a human, write it down:
{
"permissions": {
"ask": [
"Bash(git push origin main)",
"Bash(git push origin master)"
]
}
}
The push example above uses ask
on purpose: you still want to push eventually, just with a human in the loop first. That’s different from an invariant you never want crossed at all, “no data exposed, ever,” say, in a CLAUDE.md
file. A rules file states that kind of invariant as a request Claude tries to honor. A deny rule enforces it: a request the tool can’t route around, in any mode, on any day you forget you’re in auto mode at all.
A gate automation can’t talk itself out of #
Rules cover what you can name in advance. Hooks cover what you want checked every time, mechanically, regardless of what the classifier decides. A PreToolUse
hook can inspect a tool call before it runs and block it outright, deterministically, with no probability involved:
{
"hooks": {
"PreToolUse": [
{
"matcher": "Bash",
"hooks": [
{
"type": "command",
"if": "Bash(git push *)",
"command": "${CLAUDE_PROJECT_DIR}/.claude/hooks/require-green-tests.sh"
}
]
}
]
}
}
bash
#!/bin/bash
if ! npm test --silent; then
echo '{"hookSpecificOutput":{"hookEventName":"PreToolUse","permissionDecision":"deny","permissionDecisionReason":"Tests are red, push blocked"}}'
else
exit 0
fi
The if
field narrows this to git push
calls specifically, the script runs the test suite, and a failing suite returns a deny
decision that blocks the push outright, exit code 2 works the same way with a plain stderr message. Nothing here asks a classifier to judge intent. It’s a yes/no gate on a fact you can check.
Review moves, it doesn’t disappear #
None of the above replaces reading the diff. It changes what “reading the diff” is for. I wrote before about how agentic development turned most of the job into review, and the failure mode there isn’t that people stopped reviewing, it’s that review quality degrades under volume exactly the way the approval-fatigue numbers above describe. Auto mode doesn’t fix that. It just removes the low-value prompts so the review that’s left can, in theory, be the kind that actually catches something.
In practice that means picking one point in the loop where you deliberately stay the bottleneck, on purpose, and the push to a shared branch is the obvious candidate. It’s the one action that’s genuinely hard to undo and visible to someone else the moment it happens. Everything upstream of that, a wrong edit, a bad approach, a half-finished refactor, is still local and still reversible. Hallucinated code compiles and passes a quick glance; it doesn’t survive someone actually reading it against what they asked for. That reading has to happen somewhere. Put it at the boundary that matters and let the classifier and the hooks handle the volume everywhere else.
Tests are the check that doesn’t get tired #
The hook above only works because there’s a test suite behind it. That’s the other half of the strategy: tests are the executable version of “did this actually do what I asked”, and unlike a human on prompt four hundred of a session, they don’t get less careful over time. Write them before or alongside the change, not after, and the git push
gate above stops being a formality and starts being the thing that actually catches a regression a tired reviewer would have waved through.
Stacking checks that fail differently #
None of this makes the miss rate zero, same as auto mode itself doesn’t. The point isn’t finding the one control that eliminates risk. It’s stacking controls that fail in different ways, so the same blind spot doesn’t line up twice. The classifier catches the obvious and the fast. Deny rules catch the specific thing you already know matters. Hooks catch what you can specify as a check. Tests catch what you can assert. And a deliberate human read at the point something becomes shared catches the one thing none of the above can judge: whether this was the right thing to build in the first place.
Thirteen point six percent is a bad number for humans working alone. Eighty-nine percent is a good number for a classifier working alone. Neither one is the number that matters. The number that matters is what’s left over once you’ve stacked both, plus the checks that are actually yours to configure.
Sources #
Auto mode is now the default in Claude Code for Pro, Max, and Team plans: the announcement this post responds to, including the 1,053-tester study and the real-session audit numbers.How we built Claude Code auto mode: a safer way to skip permissions: the technical writeup covering the classifier’s two-stage design and what it’s built to catch.Choose a permission mode: official documentation ondefault
,acceptEdits
,bypassPermissions
, and how permission rules interact with each mode.Hooks reference: official documentation on hook events, matcher syntax, and thePreToolUse
block/allow contract used in the example above.