Anthropic's Claude Code Auto Mode Catches Dangerous Commands 89% of the Time

Claude Code's auto mode becomes the default permission system for Pro, Max, and Team users on August 14. The change is backed by hard data: Anthropic's AI classifier outperformed human reviewers on every safety metric they tracked, which is what drove the decision to make it the default rather than an opt-in feature.

Why human approval stopped working

The original permission model asked you to approve every shell command, file write, and tool call before it ran. Users approved 97% of all prompts. After 50 or more prompts in a session, the human catch rate for genuinely dangerous commands dropped to around 5%. The dialog had become a rubber stamp.

The situation compounded over time. By mid-2026, nearly half of active CLI users had manually created broad Bash allow-rules, and 62% had either used bypassPermissions or clicked "don't ask again" on shell commands. The safety net was being quietly dismantled by the people it was meant to protect.

A classifier that actually pays attention

Auto mode replaces human approval with a dedicated classifier that runs on every tool call before it executes. The architecture has two layers:

• Input layer: A server-side probe scans everything Claude reads from external sources (file contents, web fetches, shell output) for prompt injection attempts. When it detects something suspicious, it adds a warning to Claude's context before the content is passed along.
• Output layer: A two-stage transcript classifier evaluates each action before it runs. Stage 1 is a fast single-token yes/no filter tuned to block aggressively. Stage 2 runs chain-of-thought reasoning only on what Stage 1 flags, cutting false positives from 8.5% down to 0.4%.

A key design choice: the classifier only sees user messages and raw tool calls, never Claude's own reasoning or tool outputs. This makes it structurally resistant to prompt injection, since a malicious payload in a fetched file never reaches the classifier. It also prevents Claude from using in-context reasoning to talk the classifier into a bad decision.

The numbers that drove the decision

Anthropic ran a controlled study with 1,053 paid testers. Partway through each session, a single permission prompt was secretly swapped for a clearly dangerous command. The testers never ran anything harmful; only the text they saw was changed. The results:

• Human testers caught the dangerous command 13.6% of the time overall
• After 50+ prior prompts, that dropped to roughly 5%
• Auto mode blocked the same commands 89% of the time, flat across session length
• Head to head: auto mode blocked 800 commands that a human approved; humans blocked only 6 that auto mode allowed

The gap held in production data too. Among flagged sessions from May to June 2026, sessions running manual approval contained serious unintended harm more than twice as often as auto mode sessions. At production-level severity, 6.3% of manually approved sessions contained a harmful action the user hadn't explicitly requested, versus 2.4% for auto mode.

Red-teaming and prompt injection

Anthropic also commissioned third-party security work. Apollo Research ran a two-week red-team exercise, injecting synthetic attacks into real coding trajectories. After Anthropic hardened the classifier based on Apollo's findings, the miss rate fell from 12% to 7% on a held-out attack set that Anthropic never had access to. That generalization matters: it suggests the hardening wasn't just patching specific known attacks.

A separate evaluation by Trajectory Labs tested 720 indirect prompt injection scenarios across Claude Code and Codex. The attacks were designed to cause irreversible real-world harm: data exfiltration, financial fraud, credential phishing. Zero attacks succeeded against Claude Fable 5, Opus 5, or Sonnet 5 running auto mode. GPT-5.6 Sol running Codex's Auto-review mode had a 5.83% attack success rate.

What it blocks, and what it doesn't

Most routine actions (file reads, in-project edits, code navigation) are allowed immediately without touching the classifier. Only actions with real downside potential go through full evaluation. The default block rules cover four categories:

• Destroy or exfiltrate: force-pushing over git history, mass-deleting cloud storage, sending internal data externally
• Degrade security posture: disabling logging, installing SSH keys or cronjobs, modifying the agent's own permission config
• Cross trust boundaries: running code cloned from external repos, scanning credential stores, sending data to unspecified services
• Bypass review or affect others: pushing directly to main, running production deploys, modifying shared resources the agent didn't create

Some categories are hard denies that can't be overridden without switching modes entirely. Data exfiltration is one of them. If Claude needs to send your code somewhere external, it has to stop and ask you directly.

The honest limitation: the classifier has a 17% false-negative rate on real overeager actions from internal sessions. Most misses happen when the classifier correctly identifies the danger but finds something that looks like user consent in the session history, then stops short of checking whether that consent actually covers the blast radius of the action. Anthropic notes this is still a major improvement over --dangerously-skip-permissions, but it's not a substitute for careful human review on high-stakes infrastructure changes.

When the classifier blocks, Claude keeps going

When auto mode blocks an action, it sends the denial back to Claude as a tool result with an instruction to find a safer path. Claude usually does. Only after 3 consecutive blocks or 20 total blocks in a session does it fall back to asking the user directly. This deny-and-continue behavior is what makes long-running tasks viable. A 0.4% false positive rate would be unusable if every false positive killed the session.

What this unlocks in practice

The practical payoff is uninterrupted long-horizon work. Teams already running auto mode as their default are seeing measurable results:

• Adobe built an agentic loop that builds UI, then loops back to verify it matches the intended design and fixes issues automatically before any engineer reviews it
• Nuro runs overnight research agents that hill-climb evaluation metrics and return finished PRs by morning
• Gusto adopted auto mode specifically to stop engineers from bypassing permissions out of fatigue; about 10% of sessions see a classifier denial, showing it's doing real work
• Garner Health pushed auto mode to all 550 employees via managed settings, replacing hand-curated command allowlists

Across Teams and Enterprise adopters, auto mode users ship about 25% more PRs than those on manual approval.

How to configure it

For Pro, Max, and Team users who haven't set a default permission mode, new sessions will start in auto mode automatically after August 14. If you've already set a different default, you'll get a one-time prompt asking if you want to switch. You can toggle modes anytime with Shift+Tab in the CLI or the mode dropdown in the desktop app.

For Enterprise and API users, auto mode stays opt-in for now, with Anthropic planning to make it the default across all plans within the coming month. Enterprise admins can enable it org-wide via managed settings using the defaultMode config key, or disable it entirely with disableAutoMode.

One billing change takes effect immediately: the classifier's token overhead no longer counts toward usage limits on Pro, Max, and Team plans. Anthropic absorbs the cost of running the safety layer. Enterprise and API plans get the same treatment once auto mode becomes their default.

The broader finding here is worth sitting with. For agentic coding work, automated safety review can outperform human review at scale. The bottleneck was never whether AI could make good decisions; it was whether humans could sustain attention across hundreds of decisions per session. The data shows they can't. The auto mode docs cover full configuration options for teams that want to customize block rules, trust boundaries, and hard deny categories.