Claude Code Stops Asking Aug 14. Prompts Aren't Policy.

If your AI coding control says "the developer approves each action," that control expires on Friday. Anthropic confirmed on August 7 that starting August 14, 2026, new Claude Code sessions on Pro, Max and Team plans run in auto mode by default — a classifier decides, and the prompt you were counting on never appears.

The part that should worry you is not the default. It is what happens to the guardrails you already wrote. In auto mode, a boundary you stated in chat, and to a lesser degree an instruction in your project's CLAUDE.md, is an input to a classifier — not a gate. Anthropic's own documentation is blunt about which of your controls is a guarantee and which is a suggestion. Almost nobody has read that page.

---

What Actually Changes on August 14

The change is a default flip on three plan tiers, staged so that the tier enterprises buy moves first among the consumer plans. "Starting on August 14, new sessions on Pro, Max, and Team plans will run in auto mode," the announcement says. Enterprise, API and cloud-platform deployments — Bedrock, Google Cloud's Agent Platform, Microsoft Foundry — stay opt-in "for now," with plans to change that within a month.

Read the staging carefully, because it is the trap. Team is a plan your finance org actually expenses. And your engineers on personal Pro and Max seats — the ones running Claude Code against your repos on a company laptop, on a card you don't see — flip on the same day regardless of what your Enterprise tenant does.

Existing users are handled gently: if you already pinned a default, the docs say "a default you set yourself stays in place unless you accept the one-time switch prompt, and a default your organization manages is unchanged." That is the escape hatch. It only helps organizations that pinned something. Most pinned nothing, because until this week the default was the control.

In auto mode, what runs without a prompt is broader than most leaders assume: local file operations, dependency installs, reading .env and sending credentials to their matching API, read-only HTTP, and — this is the one — pushing to any branch of the repository you are working in, including the default branch, plus opening a pull request that matches your request. That default got looser over time, not tighter. Before v2.1.203, any direct push to the default branch was blocked. Before v2.1.211, only your working branch, branches Claude created, and routine default-branch pushes were allowed.

---

Your Written Guardrail Steers the Classifier. It Doesn't Stop It.

Anthropic publishes a three-row table that is the single most important thing an engineering leader can read this week, and it distinguishes three kinds of boundary by how firm they are. From the auto mode configuration page:

Boundary	Mechanism	Behavior in auto mode
Prompt before the action	permissions.ask	Always prompts for content-scoped rules. "The classifier cannot auto-approve a matching action."
Never run the action	permissions.deny	"Blocks before the classifier is consulted. Neither the classifier nor user intent can override it."
One-off boundary in conversation	"don't push until I review"	Blocks matching actions, but "the boundary can be lost if context compaction removes the message that stated it."

That third row is the one that turns a policy into a hope. Boundaries you state in chat are not stored as rules — the classifier re-reads them from the transcript on every single check. A long session that compacts its context can drop the message that carried your instruction, and the boundary goes with it. The docs' own advice: "Use an ask or deny rule for a durable guarantee."

CLAUDE.md is better than that, and it is worth correcting a widespread misreading: the classifier reads the same CLAUDE.md content Claude itself loads, so it is reloaded rather than lost at compaction. But it is still prose, weighed inside a probabilistic gate, and it sits at the softest tier of the precedence order. Inside the classifier, hard_deny blocks unconditionally, soft_deny blocks next, allow rules override matching soft blocks — and then "explicit user intent overrides the remaining soft blocks." The docs give the example plainly: asking Claude to "clean up the repo" does not authorize a force push, but asking it to "force-push this branch" does.

The definition worth memorizing: a deny rule is a permission rule evaluated by Claude Code before the classifier ever runs; a classifier rule is natural-language prose that a model weighs against the session's context. One of those is enforcement. The other is persuasion with good odds.

---

The Managed-Settings Gap Almost Nobody Has Read

An organization-wide soft_deny rule can be overridden by a single developer's personal settings file, and Anthropic says so in writing. This is the finding that should change what you do this week.

The classifier reads its autoMode configuration from user settings (~/.claude/settings.json), from managed settings, and from inline JSON — and entries from each scope are combined. Then comes the sentence: a developer "can extend environment, allow, soft_deny, and hard_deny with personal entries but can't remove entries that managed settings provide. Because allow rules act as exceptions to soft block rules inside the classifier, a developer-added allow entry can override an organization soft_deny entry: the combination is additive, not a hard policy boundary."

So if your platform team ships "never run database migrations outside the migrations CLI" as an autoMode.soft_deny in managed settings — the example the docs themselves use — one engineer with a matching allow line in their home directory clears it. Anthropic's remedy is stated in the same note: for actions that must never run regardless of user intent or classifier configuration, use permissions.deny in managed settings, "which blocks the action before the classifier is consulted and can't be overridden."

Two more configuration facts that belong in your rollout ticket:

• The classifier does not read autoMode from project settings at all — not from .claude/settings.json, not from .claude/settings.local.json. Both live in the repo, so a checked-in file or a build step could otherwise inject its own allow rules. You cannot ship auto mode policy in the repo. It has to come from managed settings or the developer's home directory.
• Narrow allow rules bypass the classifier entirely. Auto mode suspends only the broad rules that grant arbitrary code execution — Bash(*), wildcarded interpreters like Bash(python*), package-manager run commands, Agent allow rules. A narrow rule like Bash(npm test) carries over and resolves before the classifier, so, in the docs' words, it "can still let a destructive argument through without the classifier seeing it." Setting autoMode.classifyAllShell to true closes that, at the cost of a classifier round-trip on every shell command.

The same enforcement gap has now shown up in every layer of the agent stack — standing IAM permissions that let one agent escalate another, and the 77% of firms that wrote an AI agent policy against the 26% that can enforce one. Written intent is not a control surface. It never was.

---

The Numbers Anthropic Published, Including the Bad Ones

Auto mode is measurably better than the human it replaces, and measurably imperfect — and the company published both halves, which is more than most vendors do.

The case for it is strong. Anthropic hired 1,053 paid testers through a research vendor for a coding study. Human reviewers caught 13.6% of dangerous commands. Auto mode caught 89%. Know the design before you quote those numbers at your leadership team: each tester worked in a test environment on an investigative task, knowing they were in a study, and a single approval prompt mid-session was swapped for one clearly dangerous command — Anthropic chose the commands, and approving the prompt never ran anything dangerous. So 13.6% and 89% are 143 and 937 out of 1,053 single planted instances. That measures who notices one obvious bad command in a stream of prompts. It does not measure whether either reviewer catches destruction buried in a real repository. Worse for the human side, attention decayed exactly as you would predict: testers "blocked about 17% of dangerous commands early in a session, dropping to about 5% after 50 or more prior prompts." Across real usage, users approve 97% of permission prompts in Claude Code. At production-level severity, 6.3% of manually approved sessions contained a harmful action the user had not asked for, versus 2.4% of auto mode sessions.

If your control narrative is "a developer reviews each action," that study says your control was already fictional. It was a clickthrough.

Now the other half. The engineering write-up, published back in March, reports a two-stage classifier — a fast single-token filter, then a chain-of-thought re-evaluation to cut false positives — and publishes its miss rates. On real overeager actions, the full pipeline has a 17% false-negative rate; the post calls that "the honest number." Read that one with its base attached: it is 17% of 52 real cases, so it is an order of magnitude rather than a precision instrument, and it predates this week's announcement by nearly five months. On 1,000 synthetic data-exfiltration attempts, 5.7%. False positives on 10,000 real internal traffic samples come in at 0.4%. Anthropic's own scope statement: auto mode "is not a drop-in replacement for careful human review on high-stakes infrastructure."

The 89% and the 17% are not contradictory, and you should not blend them — they come from different populations. The honest summary is that a probabilistic reviewer that never gets tired beats a human reviewer who stops reading after the fiftieth prompt, and neither is a boundary.

Structurally, the classifier is deliberately deaf to some things. It sees your messages, the tool calls, and your CLAUDE.md. Assistant text is stripped — "so the agent can't talk the classifier into making a bad call" — and tool results are stripped as injection defense. Which leaves the failure mode Simon Willison flagged: he grants that auto mode beats approval fatigue, then says of the safety claims, "I'd like to see more independent confirmation of this," and argues the real answer is running agents that "don't have access to data or tools that can cause harm" rather than detecting harm after the fact. More is the operative word, because some exists and it is good: Anthropic commissioned Trajectory Labs to run 72 indirect prompt-injection scenarios held out from its own training, ten times each, and none of the 720 attempts succeeded against auto mode on Fable 5, Opus 5 or Sonnet 5, versus 5.83% succeeding against GPT-5.6 Sol in Codex's auto-review mode. Two caveats travel with it: the vendor being evaluated paid for the evaluation, and Anthropic states it measures the underlying model rather than a full deployment, on versions current as of July 17. That is the same lesson as agentjacking via fake bug reports and the worm that reinfects through agent config: detection is a layer, not a perimeter.

Steel-manning the other side properly: Boris Cherny, who heads Claude Code, told TechCrunch that "the team and I use Auto mode exclusively, and have been for many months. I couldn't imagine going back to permission prompts!" For reversible work inside a version-controlled repo, that is a defensible position, and the original auto mode announcement still recommends isolated environments. The argument is not that auto mode is bad. It is that the thing you wrote down is not what stops it.

---

One More Thing That Isn't Configurable

When the classifier blocks an action 3 times in a row or 20 times in total, auto mode pauses and Claude Code resumes prompting — and those thresholds cannot be changed. Approving the prompted action resumes auto mode. Any allowed action resets the consecutive counter.

That matters in two directions. In an interactive session it is a reasonable circuit breaker. In non-interactive mode with the -p flag — which is how most CI jobs, scheduled agents and internal automation run Claude Code — there is no user to prompt, so repeated blocks abort the session outright. If you have pipelines that shell out to Claude Code, a tightened classifier or a newly-added deny rule can turn a working job into a hard failure with no human in the loop to notice. Budget for that before Friday, not after.

One cost note, since somebody will ask: Anthropic stopped charging Pro, Max and Team users for classifier overhead effective the announcement. On Enterprise plans and on API, AWS, Bedrock, Agent Platform and Foundry accounts, classifier calls still count toward your token usage — each check sends a portion of the transcript plus the pending action.

---

What to Do Before Friday

This Week (before August 14):

1. Decide the default in writing, then pin it. Either set permissions.defaultMode in managed settings, or set permissions.disableAutoMode to "disable" to remove auto mode from the Shift+Tab cycle and reject --permission-mode auto at startup. Doing nothing is also a decision — it is the decision to accept the flip.
2. Find your managed settings file and confirm it deploys. It lives at /Library/Application Support/ClaudeCode/ on macOS, /etc/claude-code/ on Linux and WSL, and C:\Program Files\ClaudeCode\ on Windows, per the settings reference, each supporting managed-settings.json and a managed-settings.d/ drop-in directory. If you cannot answer "how does a policy change reach 300 laptops," you have no controls at all — you have a wiki page.
3. Convert your top five written prohibitions into rules. Every "never touch prod," "never force push," "never modify the migrations directory" in a CLAUDE.md becomes a permissions.deny entry in managed settings. Deny beats ask beats allow, and a broad deny like Bash(aws *) blocks every matching call even when a narrower allow rule matches — deny rules carry no exceptions.
4. Add permissions.ask checkpoints for push and PR. "ask": ["Bash(git push *)", "Bash(gh pr create *)"] keeps auto mode on for everything else while forcing a prompt on the two actions that leave your machine.
5. Inventory the personal seats. Your Enterprise tenant is opt-in; the Pro and Max seats your engineers expensed are not. Ask, in Slack, today, who runs Claude Code on a personal plan against a company repo.

This Month:

6. Fill in autoMode.environment. The classifier trusts only your working directory and its configured remotes by default; everything else is a potential exfiltration target. Name your source-control org, internal registry, CI, buckets and — critically — your sensitive data locations and protected IaC scopes, so the protective rules target real names instead of a prod-in-the-hostname heuristic. Then run claude auto-mode config to confirm what actually took effect, and claude auto-mode critique on any custom rules.
7. Set autoMode.classifyAllShell to true if you carry narrow shell allow rules, and evaluate allowManagedPermissionRulesOnly, which stops user and project settings from defining allow, ask or deny rules at all. Note what it does not cover: it governs the permissions block, not autoMode, so it does not stop a developer adding an autoMode.allow entry. The remedy Anthropic names for that gap is a permissions.deny rule in managed settings.
8. Re-run your agent tabletop with the prompt removed. Every incident scenario you rehearsed that ends "…and the developer would have caught it at the approval dialog" now needs a different ending. Nine seconds was enough to drop a production database when a human was still nominally in the loop.

Before Your Next Audit:

9. Rewrite the control description. If a SOC 2, ISO 42001 or internal-audit control says "developer approval required for AI-generated changes," the evidence for it is now a settings file, not a habit. Screenshot claude auto-mode config and your managed settings, and attach the version — these defaults changed materially across four point releases this summer.

---

The Bottom Line

We have run this play before. Every platform that moved from "the human clicks yes" to "the system decides" — cloud IAM, CI/CD deploy gates, EDR auto-remediation — went through the same eighteen months, and the organizations that came out fine were the ones that stopped writing intentions and started writing rules. The ones that got burned had excellent documentation.

Anthropic did not hide any of this. The miss rate is published, the precedence order is documented, the sentence saying your org policy is "not a hard policy boundary" is right there in the configuration reference. The gap is not disclosure. It is that a generation of AI governance got written as prose, and prose was never load-bearing.

You have four days. A control that lives in a paragraph is a preference. Put it in a deny rule or admit you don't have one.

Continue Reading

One Agent Escalated Another. Every Call Was Authorized.

77% Wrote AI Agent Policies. Only 26% Can Enforce Them.

Agentjacking: AI Agents Hijacked via Fake Bug Reports

npm Pulled the Packages. Your Agent Config Reinfects You.

9 Seconds to Delete a Production Database: The AI Agent Crisis

ServiceNow Just Fenced In Cursor, Copilot, Claude Code

Best AI Coding Assistant at 500 Seats: Buy Copilot Business

10,000 AI Failures Exposed. Hallucination Isn't #1.