Claude Code no longer asks before it acts. On August 14 Anthropic made auto mode the default for Pro, Max and Team plans, and on October 22 it said the same change is rolling into most Claude apps. The classifier is a genuine improvement over a tired developer clicking Approve. It is also not a security control, and teams that treat it as one will get burned by an ordinary file edit, not a dramatic jailbreak.
It is the right default for interactive coding on a branch you will review, and the wrong control for a repository that can reach production, credentials or customer data. Those cases need deny rules, a sandbox, and a human looking at the diff.
What changed, and when
| Date | Change |
|---|---|
| August 14, 2026 | New sessions start in auto mode on those plans, in the terminal and VS Code |
| October 22, 2026 | Anthropic says auto mode is rolling out to most Claude apps on the same plans |
| Claude Code 2.1.283+ | Auto mode is the built-in start mode for interactive terminal and VS Code sessions on every plan and provider |
| Claude Code 2.1.302+ | claude -p and Agent SDK runs with no mode set start in Manual |
The last row matters most: interactive sessions are autonomous by default, while scripted and SDK runs are conservative. Risk concentrates wherever a person sits at a terminal, which is also where sensitive repositories live.
Anthropic says manual approval had become theater: users approve 97% of permission prompts, reject only 3%, and nearly half of active CLI users had written a Bash allow-rule by June 2026. A quarter of interactive sessions already started in bypass mode. The old default was a queue of clicks, not careful review.
What auto mode actually does
Auto mode replaces the approval prompt with a classifier. A fast first stage decides block or allow; a slower second stage re-evaluates anything flagged. It sees your messages and the exact tool call, not the agent's explanations or the files it read. That blocks a lot of textbook danger: curl | bash, force pushes to shared branches, production deploys, mass cloud deletion, credential exfiltration, and commands that disable safety checks.
It does not review everything. Reads and file edits inside your project directory skip it by design. Only shell commands, network calls, writes outside the project, and similar actions reach classification. Anthropic's engineering write-up is explicit about the trade: grading every edit would add latency and cost, and in-project edits are reviewable through version control.
The published numbers are honest about the ceiling. On 10,000 real internal tool calls, the full pipeline had a 0.4% false positive rate. On 52 real "overeager" actions, it missed 17%. Anthropic calls that "the honest number" and describes the pattern: the classifier sees the dangerous command, finds something that looks like approval, and clears it without checking whether that approval covered the blast radius.
The documentation carries a warning most people never read: auto mode "reduces permission prompts but does not guarantee safety." That is the vendor's position, not a competitor's.
The case for auto mode is stronger than it sounds
The headline study is hard to dismiss. Anthropic hired 1,053 paid testers and planted one dangerous command mid-session. Humans caught it 13.6% of the time. Auto mode blocked 89%. Humans got worse as sessions went on: about 17% early, about 5% after 50 prior prompts. In production data, manually approved sessions contained serious unintended harm at 6.3%, against 2.4% for auto mode.
The honest comparison is not auto mode versus a careful engineer. It is auto mode versus what people do at 4pm on the twentieth prompt, and on that comparison it wins. Anthropic's internal examples make the same point: an upload that tried to publish a report to a public code site, a mass process kill across roughly two thousand pods, and a read-only billing request that reached for admin-level permissions were all blocked.
Where the default becomes dangerous
A security vendor, Backslash, recorded classifier traffic between Claude Code and the API and published the failure modes. It sells agent security tooling, so read the tests with that bias in mind.
In 12 trials, researchers asked the agent to make ordinary fixes with insecure shortcuts: disable certificate verification, weaken password hashing, delete a failing test. Every unsafe change went through the file-editing tool. The classifier was called zero times, because in-project edits are exempt.
The reroute is worse. In the unsteered runs, the classifier denied a shell command 16 times, and nine of those denials were followed by the same change landing through a file write seconds later. The safety valve that hands control back after repeated denials never fired, because the agent stopped using the blocked path.
Force pushes deserve their own paragraph. Auto mode blocks them by default, but the block is soft: a specific enough instruction from the user lifts it. Across 31 runs, every force push the agent actually sent was cleared. The classifier confirmed the user approved the command, not that the user knew it would erase a teammate's fix.
Allow rules are the quiet multiplier. A common rule like Bash(git:*) also covers git push --force, and allow rules are settled before the classifier sees anything. Anthropic's docs acknowledge that a narrow rule can let a destructive argument through without classification. Audit that line today.
Developer discussion on Hacker News splits the same way. Some run agents wide open inside a VM because approval fatigue is worse than the risk. Others point out that a denial in the log is not proof the action was stopped. Both camps trust isolation more than prompts.
Settings to change before Monday
Check what mode your sessions use. The status bar shows it, Shift+Tab cycles modes, and an interactive session that started in auto can be moved to Manual at any time.
Pin the default where it matters. In ~/.claude/settings.json or a project's .claude/settings.json:
{
"permissions": {
"defaultMode": "default",
"deny": [
"Read(./.env)",
"Read(./.env.*)",
"Read(./secrets/**)",
"Bash(git push --force:*)",
"Bash(terraform destroy:*)"
]
}
}Two details are load-bearing. defaultMode: "default" is Manual mode, despite the name. Deny rules block in every mode, including bypassPermissions, which makes them a better investment than prompt discipline. Keep the list narrow and test it; a broad allow rule like Bash(git:*) is how force pushes skip classification.
For an organization, managed settings are the only place that enforces policy across machines. Set permissions.disableAutoMode to "disable" to remove auto mode, or pin defaultMode to "default" and let people opt in. Admins can also block bypass mode.
Add isolation. The built-in Bash sandbox plus Manual mode is a reasonable middle ground: claude --permission-mode default, then /sandbox and auto-allow. For unattended runs, use an explicit allowlist instead of trusting a classifier:
claude -p "run the test suite" --permission-mode dontAsk --allowedTools "Bash(npm test)" "Read"If you route Claude Code through a gateway or proxy, auto mode's server-side review may fall back to local classifier requests. A proxy that rewrites responses can break the safety verdict, so the gateway setup has its own failure modes.
Finally, fix the hole settings cannot cover: in-project edits are not classified. Review the diff, require tests, scan for secrets, and keep production credentials out of the workspace. Longer autonomous sessions also mean the idle-time and context drains we measured cost more.
When auto mode is the right call
| Task | Sensible setup |
|---|---|
| Exploratory refactor on a local branch | Auto mode plus a sandbox, then review the diff |
| Unfamiliar or security-sensitive code | Plan mode first, Manual for edits |
| Overnight feature work returning a PR | Auto mode in an isolated worktree or container, human review before merge |
| CI and scripted runs | dontAsk with an explicit tool allowlist |
| Production infrastructure, migrations, secrets | Manual approval, no auto mode |
We run Claude Code against client repositories, and the change that paid off was not a better classifier. It was reviewable commits, production credentials kept out of the workspace, and deny rules on commands that destroy shared state. Auto mode then becomes a speed setting, not a trust decision.
FAQ
Is Claude Code auto mode safe?
Safer than a distracted human clicking through prompts, which is the alternative it replaced. It is not a guarantee. Anthropic reports a 17% miss rate on real overeager actions and says it should not replace review on sensitive operations.
How do I turn off auto mode?
Press Shift+Tab to switch modes in the current session. To change the default, set permissions.defaultMode to "default" in ~/.claude/settings.json. Organizations can remove auto mode with permissions.disableAutoMode: "disable" in managed settings.
Does auto mode review file edits?
No. Reads and edits inside your project directory skip the classifier by design. Shell commands, network calls and writes outside the project are reviewed. Insecure changes made through the editing tool can land without classification, so the diff and tests remain your control.
