Starting August 14th, Claude Code switches its default behavior for Pro, Max, and Team plan users: auto mode, which lets Claude execute multi-step coding tasks without asking for approval on each action, becomes the out-of-the-box setting instead of an opt-in feature. This article covers what auto mode actually gates, what Anthropic's own evaluation numbers say about its effectiveness, and where the remaining gaps are.
What auto mode changes
Claude Code has always been able to read files, run commands, and edit code as part of an agentic loop. What differs between "manual" and "auto" mode is the approval checkpoint: manual mode pauses before file writes, shell commands, or other potentially consequential actions and waits for a human to click approve; auto mode runs through a task and only pauses when it hits an action its own safety classifier flags as risky.
Making that the default doesn't add new capability to the tool — Claude could already do everything auto mode does, if a user manually approved every step. The change is about who has to make the approve-or-block decision on each individual action: previously, the human did, by default, for everything; now, a built-in classifier does, by default, for most things, and the human only sees the actions that classifier considers worth a second look.
Auto mode doesn't make Claude Code capable of anything it couldn't already do — it changes who has to review each step before it happens.
What the safety numbers say
Anthropic released evaluation results alongside the rollout. In controlled testing, auto mode's built-in classifier blocked 89% of commands that were independently rated as dangerous — notably, 86.4% of human testers in the same trial approved those same commands when reviewing manually. That comparison is the core of Anthropic's pitch: humans reviewing agent actions one at a time, without full context on what the multi-step task is actually doing, approve harmful commands at a meaningfully higher rate than the automated classifier does.
Separately, third-party testing by Trajectory Labs ran 720 attempts at indirect prompt injection — attacks that hide malicious instructions inside content the model reads, like a webpage or a file, rather than inside the user's direct prompt — against Claude models running in auto mode, and found zero successful attacks in that test set.
| Metric | Result |
|---|---|
| Dangerous commands blocked by auto mode | 89% |
| Same dangerous commands approved by human reviewers | 86.4% |
| Prompt injection attempts tested (Trajectory Labs) | 720 |
| Successful prompt injection attacks in that test | 0 |
Those are strong numbers for a first release, and they're the reason Anthropic feels comfortable flipping the default rather than leaving auto mode as an advanced, opt-in setting.
Where the gap still is
Simon Willison, who has tracked prompt injection against coding agents closely, flagged the number that the 89% figure implies from the other direction: 11% of harmful actions in that test still got through the classifier. For a feature that's about to run by default for a large population of Pro, Max, and Team users, an 11% miss rate on actions independently judged dangerous is not a rounding error — it's a rate at which some fraction of real-world sessions will hit an unblocked harmful action.
Willison's second concern is about attack surface the 720-attempt test may not have fully covered: malicious third-party packages with instructions hidden in their documentation or README files. An agent that reads a package's docs as part of understanding how to use it is reading attacker-controlled text by definition, and a classifier tuned against direct prompt injection in web content is not automatically tuned against instructions buried in a dependency's own documentation, which a coding agent has every reason to read as part of normal work.
A single strong benchmark result against one attack pattern doesn't guarantee the same defense holds against a differently shaped attack the benchmark didn't test.
What this means for builders
Teams adopting Claude Code auto mode as it becomes the default should treat the classifier as a meaningfully strong first line of defense, not a substitute for existing controls — sandboxed environments, scoped credentials, and code review before merge remain relevant regardless of how good the pre-execution classifier is, because 11% of missed dangerous actions is a real number for teams operating at volume, and the classifier's blind spots may not line up with the ones it was tested against.
Teams that install third-party packages as part of an agent's workflow should be specifically cautious: if an agent is going to read a dependency's documentation to figure out how to use it, that documentation is untrusted input in exactly the way a webpage would be, whether or not the auto mode classifier was benchmarked against that specific pattern.
Conclusion
Auto mode's numbers — 89% of dangerous commands blocked, zero successful prompt injections in 720 attempts against the tested pattern — are a real result, not marketing. But a benchmark measures what it tests, and the honest reading of "89% blocked" is "11% not blocked," at population scale, for actions serious enough that a classifier is meant to catch them. Teams switching to the new default should keep the layers of protection they already had rather than treating auto mode as the only one they need.