Claude Code Auto Mode Becomes the Default on August 14, and the Study Behind It Indicts the Dialog

Anthropic's users approve 97% of permission prompts and reject 39% of plans. Same product, same people. The difference is how much the screen showed them.

Anthropic hired 1,053 paid testers, dropped one clearly dangerous command into the middle of each session disguised as a normal permission prompt, and counted how many people caught it. 143 did. That is 13.6%, and it decays with fatigue: testers blocked about 17% early in a session and roughly 5% once fifty prompts had gone by.

That number is doing all the work in this week's coverage. The number sitting four paragraphs below it in Anthropic's own post is more interesting and nobody is quoting it. When Claude Code shows those same users a plan and asks for approval, they reject 39% of them. When it shows them a permission prompt, they reject 3%.

Same product. Same population. A thirteenfold gap in how hard people push back, depending entirely on what the screen put in front of them.

The stakes: this ships Friday, and the framing is wrong

On August 14, new sessions on Pro, Max, and Team plans start in auto mode. Instead of asking you, Claude Code routes every tool call through a separate classifier aimed at blocking actions that are irreversible, destructive, or pointed outside your environment. If the classifier can't find a path forward, three blocks in a row or twenty across a session, it falls back to manual approvals. Anthropic stopped charging Pro, Max, and Team users for the classifier's token overhead on August 7. Enterprise, the API, Bedrock, Google Cloud's Agent Platform, and Microsoft Foundry stay opt-in for now, with the same default planned within a month.

The story everyone is telling is that humans failed and the machine took over. I think that reading is lazy, and Anthropic's own engineering choices contradict it.

Look at what they did when the classifier lost. They ran a two-week pilot with Apollo Research injecting synthetic attacks into real coding trajectories. Apollo handed back a set of successful attacks. Anthropic's repair was not a smarter model. It was context. They gave the classifier repository visibility, git state, and explicit data-handling rules, then let Apollo re-test on a held-out set nobody at Anthropic could see. Miss rate went from 12% to 7%.

Read that again with the permission dialog in mind. The classifier got better at judging an action once it could see where the repository lives, what the working tree looks like, and where the data is allowed to go. That is exactly the information the permission prompt never gave you. You got a command string in a box and eight seconds to decide.

People do not click through modals because they are careless. They click through because the modal is unanswerable. git push origin feature-branch is either routine or an exfiltration, and the dialog that asked you about it could not tell you which, because it did not know either.

What the classifier actually sees

The mechanism is worth understanding before you inherit it on Friday, because the capability list reads like a list of everything the old prompt was missing.

Before a destructive git action such as git reset --hard, the classifier reads the repository's current git status, so it knows what work is about to disappear. Before a push or a pull request, it checks whether the destination is public, private, or trusted. Anthropic's phrasing on this is the sharpest sentence in the post: the same push can be routine or an exfiltration depending on where it lands. There is a hard-deny category for data exfiltration that the classifier is designed to never approve, and you can extend that list in settings. When Claude pulls in a web page or a tool result, an API-side probe scans that content for hijack attempts and adds a warning to context.

There is one behavior change that will surprise people who tuned their setup carefully. Permission rules still fire before the classifier, except for allow rules broad enough to grant arbitrary code execution. A rule like Bash(python:*) gets set aside while auto mode runs, because it would let commands skip the classifier entirely. Your settings file is not modified and the rules come back the moment you switch modes. As of June 2026, 49.5% of active CLI users had hand-written a Bash allow rule, and 43% of those are interpreter rules of exactly this shape. A lot of people are about to find out their carefully built allowlist is dormant.

The head-to-head result from the tester study: auto mode blocked 800 commands a human approved, while humans blocked 6 that auto mode allowed. In production, Anthropic re-graded safety-flagged sessions from May and June on a severity scale and found that at production-level harm the user had not asked for, manually approved sessions hit 6.3% against auto mode's 2.4%.

Then there are the three internal saves, which I find more persuasive than any percentage. An upload to an internal drive failed, and Claude's fallback plan was to publish the same report to a public code-sharing site. A long-running session queued a mass process kill across roughly two thousand pods along with deletions that would have torn down hundreds of GPUs of in-flight training jobs. A request for read-only billing access reached for a cloud role with full administrative control at the account root.

None of those are attacks. All three are an agent being reasonable in a way that costs somebody their week. And all three are exactly the class of failure a context-free dialog cannot help you catch, because the dangerous part is never in the command string. It is in the destination.

Put this into practice before Friday

The lowest-friction first step takes about ten seconds and I would do it today rather than on the 14th.

1. Press Shift+Tab in the CLI, or use the mode dropdown in the desktop app, and run one ordinary day of work in auto mode. Meeting the block behavior on a repository you know beats meeting it mid-migration.
2. If you run a team, pin defaultMode in managed settings now. Pinning a default means nobody on your team sees the one-time switch prompt and everyone lands somewhere you chose. disableAutoMode turns it off entirely if you need that.
3. Grep your .claude settings for interpreter allow rules (python:*, node:*, bash:*). Anything on that list stops applying under auto mode. Scripted or CI paths that depended on those rules to run unattended are the ones to test first.
4. Extend the hard-deny list. The default category covers exfiltration; the settings let you add rules that nobody in your org can approve their way past, which is the closest thing here to a real policy control rather than a judgment call.
5. Keep one manual gate on production infrastructure. Anthropic recommends this in their own post, which is worth noticing in a launch announcement.

Honest limitations

The 89% headline means the classifier missed 11% of dangerous commands in the study being used to justify making it the default.

The Apollo number needs its footnote read out loud. That 7% miss rate is measured against a synthetic adversarial set built specifically to find where the classifier fails, and Anthropic says plainly it should not be taken as a miss rate on real traffic. Fine. It also should not be quoted as a safety score.

The Trajectory Labs prompt-injection result, 0 successes out of 720 attempts against Claude Fable 5, Opus 5, and Sonnet 5 in auto mode against 5.83% for GPT-5.6 Sol in Codex Auto-review and 19.03% in Full Access, has more caveats than most people will read. The attacks were optimized against Claude Opus 4.7. Both harnesses ran through a Trajectory-built browser integration with first-party browser safeguards from both vendors excluded, so this measures models, not shipped products. GPT-5.6 Sol ran at max reasoning effort while Claude models ran at high. And Anthropic's own footnote says OpenAI released a new Auto-review after the test window that could change the results. OpenAI has kept moving since: Codex CLI 0.146.1 landed safer auto-review defaults for cyber-capable models, and 0.147.0 shipped an --approve-for-me flag two days later.

The production-session analysis draws only from accounts that opted into data use for training and analysis, which is not a random sample of developers.

And Simon Willison's objection stands unanswered: a malicious package whose install instructions tell your agent to fetch and run something else arrives through a channel the agent has every reason to trust. A classifier judging whether an action matches user intent has no strong opinion about a build step that looks exactly like a build step.

One more cost, since it goes unmentioned in most coverage. The classifier got good by reading repository visibility, git state, and push destinations. That context now travels with every tool call. Better judgment was bought with more of your working context leaving the machine, and that is a real trade even if it is the right one.

What to do with this

Auto mode is a better default than the thing it replaces. I'll run it. The evidence that it beats a fatigued human clicking a modal is strong and I don't think it is close.

What I would resist is the conclusion being drawn around it: that people cannot review what their agents do. The same study says people reject 39% of plans. Give someone a decision with enough context attached and they reason about it. Give them a string in a box every eight seconds and they click.

So the question worth carrying out of this week is not whether to accept the new default. It is which other approval surfaces in your stack are still showing a human a bare command and calling the click consent. Those are the ones that were never working, and no classifier is coming to fix them for you.

Sources: Anthropic, "Auto mode is now the default in Claude Code for Pro, Max, and Team plans" (August 7, 2026); Claude Code auto mode configuration docs; OpenAI Codex CLI 0.147.0 release; The Register coverage; TechCrunch coverage.