Claude Code Auto Mode

Sources#

• Auto mode for Claude Code
• Boris Cherny: We Cut 80% of Claude Code's Prompt
• Choose a permission mode
• Claude Code Changelog
• Claude Opus 5 System Card
• Configure auto mode
• Documented AI Agent Incidents
• Introducing Claude Opus 4.7

Summary#

Auto mode is a permissions mode in Claude Code that delegates per-tool-call approval to a classifier, positioned as the middle of a three-point safety spectrum: default (prompt on every write/bash) → auto mode (classifier approves safe, blocks risky, eventually escalates to prompt) → --dangerously-skip-permissions (no checks). Introduced as a research preview on the Team plan; extended to Max users alongside Opus 4.7; compatible with Sonnet 4.6 and Opus 4.6.

Details#

Mechanism#

Before each tool call runs, a classifier inspects it and returns one of three outcomes:

1. Safe → tool call proceeds automatically, no prompt.
2. Risky → blocked. Claude is redirected to try a different approach.
3. Repeatedly blocked → if Claude insists on actions that keep getting blocked, a permission prompt is eventually surfaced to the user.

The classifier targets categories that Anthropic characterizes as potentially destructive: mass file deletion, sensitive data exfiltration, and malicious code execution (full list is maintained in the Claude Code permission-modes docs).

Residual Risk#

Auto mode reduces risk vs. --dangerously-skip-permissions but does not eliminate it. Two documented failure modes:

1. Ambiguous intent: classifier can't tell whether an action is benign.
2. Missing environment context: classifier doesn't know the deployment-specific risk surface (e.g., a shared DB, a production bucket).

In both cases the classifier may allow some risky actions through. Conversely, it may occasionally block benign actions. Anthropic continues to recommend isolated environments even with auto mode on.

Cost and Latency#

Small impact on token consumption, cost, and latency per tool call (classifier runs inline). Not zero.

Availability and Toggles#

• Research preview launch: Claude Team plan; rolling to Enterprise and API plans in the coming days (as of the source post).
• Extended to Max users alongside Opus 4.7 launch (see Claude Opus 4.7).
• Disabled by default on the Claude desktop app; admins toggle via Organization Settings → Claude Code.
• Managed disable: set "disableAutoMode": "disable" in managed settings to turn it off for CLI and VS Code extension.
• Developer enable:
• CLI: claude --enable-auto-mode, then cycle to it with Shift+Tab.
• Desktop / VS Code extension: enable in Settings → Claude Code, select from the permission-mode dropdown in-session.

(Superseded 2026-09-07 by the docs reference: available on all plans and every provider, the built-in starting mode on Pro/Max/Team, no --enable-auto-mode step — see "What the docs reference adds" below.)

Intended Use Case#

Auto mode exists because Claude Code's default is deliberately conservative — every file write and bash command prompts. That safety makes unattended long-running tasks impractical: you can't kick off a multi-hour refactor and walk away. Auto mode is the middle path: long tasks with fewer interruptions, without unconditionally trusting Claude's judgment on destructive actions.

This mirrors the "fan-out and unattended runs" scaling patterns in Claude Code Best Practices — a pre-existing use case that previously forced a binary choice between approval fatigue and --dangerously-skip-permissions.

By July 2026 Boris Cherny describes auto mode as the enabling half of Opus 5's endurance claim — "combine Opus 5 with auto mode and it can go for days, weeks, months at a time" — and as the third layer of the deployed anti-injection stack (aligned model + all-traffic interpretability probe + auto-mode classifier; see Agentic Prompt Injection for the claim and its counter-evidence) (YC interview, practitioner-opinion).

Non-Interactive Mode Interaction#

When Claude Code runs non-interactively (claude -p), there is no user to answer a permission prompt. Per Claude Code Best Practices, auto mode aborts on repeated blocks in non-interactive mode rather than hanging on an un-answerable prompt — preserving the fan-out and pre-commit-hook use cases described in the best-practices guide. (Sharpened 2026-09-07: per the docs, when a -p run without --permission-prompt-tool hits a fallback threshold the blocked action is skipped and Claude keeps working — the run is not stopped.)

What the changelog window adds (v2.1.200–2.1.220, snapshot 2026-08-03)#

The Claude Code CHANGELOG (vendor-claim; rolling document, this snapshot scoped to v2.1.200–2.1.220 — the live file has moved on) is the first source to name the classifier's model and to date its scope changes. No rationale or measurement accompanies any of it.

• The classifier has a named model and a pinning rule. v2.1.210: "the permission classifier now defaults to Sonnet 5 for external sessions, validated on the session's first request and pinned for the session." Pinning removes mid-session drift — the decision boundary cannot change under a running agent — while saying nothing about release-to-release drift.
• Adjudication moved toward the classifier, away from static checks. v2.1.218: "the dangerous-rm, background-&, and suspicious-Windows-path checks no longer open permission dialogs; the auto-mode classifier adjudicates them instead," and separately "plan mode with auto no longer prompts for Bash commands the static analyzer can't prove read-only; the auto-mode classifier judges them instead." Both replace a deterministic decision with a model judgment. That is the opposite direction from Deterministic Pre-Execution Gates, which measures a state-reading predicate recovering violations a reasoning model commits — and the changelog offers no evidence either way. Worth flagging as a live divergence between shipped product and published research, not as a refutation of either.
• Two fixes target fabricated approval, which is what the white-box result predicted. v2.1.205 added "an auto mode rule that blocks tampering with session transcript files," and — more directly — "Background task notifications now explicitly state that no human input has occurred, preventing fabricated in-transcript approvals from being acted on." Read against the Opus 5 card's NLA readout decoding a hallucinated user approval just before a blocked-deletion workaround, this is the harness answering the same failure from the outside: make the absence of approval explicit in the transcript rather than relying on the model not to invent one. Convergence in timing; the changelog never mentions the card.
• Scope narrowed in three places. v2.1.205: auto mode now "asks before running rm -rf on a variable it can't resolve from context" — the missing environment context residual risk above, narrowed by escalating on unresolvable state rather than guessing. v2.1.210: catastrophic removals inside $(…), backticks, or <(…) now prompt in auto mode and --dangerously-skip-permissions, "matching the plain form." v2.1.207: auto mode no longer reads autoMode from .claude/settings.local.json (repo-resident) — a cloned repository can no longer turn the mode on.
• Availability widened. v2.1.207 made auto mode available without the CLAUDE_CODE_ENABLE_AUTO_MODE opt-in on Bedrock, Vertex AI, and Foundry (disableAutoMode to turn it off).
• The classifier is a network dependency, and it fails closed. v2.1.216 fixed "auto mode denying commands with 'HTTP 401' classifier errors after the OAuth token expired or rotated mid-session" — i.e. the bug was that a classifier transport failure was being surfaced as a denial. The behavior under classifier unavailability is deny, which is the opposite bias to the fail-open convention in Deterministic Pre-Execution Gates, and defensible for the same reason each names.

What the docs reference adds (permission-modes + auto-mode-config, snapshot 2026-09-07)#

Two rolling documentation pages — Choose a permission mode and Configure auto mode (vendor-claim, both snapshotted 2026-09-07 with published: blank by design, like the changelog) — are the first sources to describe the classifier as a system rather than a feature: a decision order, a configuration surface, and a fallback policy. Still no measurement anywhere: no false-positive rate, no precision figure. The pages' own channel for false positives is /feedback.

• Availability is no longer the constraint. All plans; on Pro, Max and Team auto mode is the built-in starting mode; on Team and Enterprise admins turn it off with permissions.disableAutoMode; on the Anthropic API, Claude Platform on AWS, Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry and signed-in Claude apps gateway sessions it is available by default (the CLAUDE_CODE_ENABLE_AUTO_MODE=1 opt-in lasted v2.1.158–2.1.206). Model floor: Opus 4.6, Sonnet 4.6 or a Fable model on the API; only Sonnet 5, Opus 4.7+ and Fable on the third-party clouds. Enterprise and API-key sessions still start in Manual.
• A fixed decision order, and MCP is inside it. (1) Explicit allow/ask/deny rules resolve first — except writes to protected paths and critical-path rm/rmdir, which reach the classifier even when an allow rule matches, and MCP tools marked requiresUserInteraction plus connector tools an organization set to ask, which prompt the human directly. (2) Read-only actions and working-directory edits are auto-approved (the first read outside the working directories prompts). (3) Everything else, MCP and custom tools included, goes to the classifier; the tools that prompted in step 1 never reach it. (4) A block returns the fixed text Blocked by classifier (v2.1.208+) and Claude tries an alternative. On entering auto mode, broad rules granting arbitrary execution — Bash(*), wildcarded interpreters, package-manager run commands, Agent, Monitor — are dropped for the duration; narrow ones like Bash(npm test) stay, unless autoMode.classifyAllShell (v2.1.193+) suspends those too.
• What the classifier sees. User messages, non-read-only tool calls, and CLAUDE.md content. Tool results are stripped, so hostile content in a file or web page cannot address it directly; a PostToolUse hook's classifierContext field is the sanctioned way to annotate a result for it, and a separate server-side probe scans incoming tool results. Before a work-discarding command Claude Code runs git status itself and shows the classifier whether staged, modified or untracked work exists. Because the classifier reads the same CLAUDE.md Claude loads, one line — "never force push" — steers agent and gate at once (Agent Context Files).
• Environment context is a configuration surface, and it is prose. autoMode.environment is a list of natural-language entries in three families: context slots (organization, primary use, cloud providers, repository visibility, host containment, …), trust slots (trusted repo, source control, internal domains, cloud buckets, key internal services, internal package registry) and sensitivity slots (sensitive data locations & audiences, sensitive remote targets, protected IaC scopes). Defaults: only the working repository and its remotes are trusted; any host or namespace named prod/production is sensitive. This is residual risk 2 above — missing environment context — turned into a settings key: the docs say repeated denials "usually mean the classifier is missing context about your infrastructure," and that naming the source-control org and key services "resolves the most common false positives like pushing to your own repos." /auto-mode-setup (v2.1.228+, Pro/Max/Team) drafts the entries from the project and recent sessions.
• Rules have tiers, and the tiers are overridable. hard_deny (unconditional; the built-in one is data exfiltration) → soft_deny (destructive actions user intent can clear: force push, curl | bash, production deploys, auto-mode bypass) → allow (exceptions to soft blocks) → explicit user intent ("force-push this branch" clears a soft block; "clean up the repo" does not). "$defaults" splices the built-in list in and, the docs note, means you "continue to inherit updates as the built-in list changes across releases"; omitting it replaces the list wholesale. Read scopes are ~/.claude/settings.json, managed settings and --settings/Agent SDK inline JSON — never project .claude/settings.json or .claude/settings.local.json, so a checked-in repository cannot loosen the gate. A developer can add an allow that overrides an organization's soft_deny; the only boundary the classifier cannot be configured past is permissions.deny in managed settings, evaluated before it runs.
• Fallback is quantified. Three consecutive blocks or twenty in total pause auto mode and resume prompting; the thresholds are not configurable; an allowed action resets the consecutive counter. A classifier request that produces no verdict (a safety check refusing the classifier's own request, an unparseable response) denies the action without counting toward either threshold and without a Recently denied entry.
• The classifier model, stated as policy. Sonnet 5 by default regardless of /model; a model Anthropic configures server-side takes precedence; when Sonnet 5 is excluded (availableModels, or a Sonnet 4.6 session) the session's model is used, or an Opus model for Fable sessions. Validated on the first request and fixed for the session — the changelog's pinning rule, now documented. On Enterprise, the API and the third-party clouds, classifier calls bill as token usage; reads and working-directory edits skip it, so the overhead is shell and network.
• Subagents get three checkpoints. The delegated task description is classified at spawn (v2.1.178+); each subagent action is classified under the parent's rules with any frontmatter permissionMode ignored; the full action history is reviewed on return, with a security warning prepended when the review flags it (or a "treat as untrusted" warning when the review request itself was refused). Agent-to-agent SendMessage traffic is classified too (v2.1.222+).
• Inspection exists. claude auto-mode defaults | config | critique | reset print the built-in and effective rule lists — each rule a labeled prose string — critique custom rules for ambiguity and likely false positives, and reset user settings. The /permissions Auto mode tab (v2.1.246+) edits them; Recently denied lists denials with r to retry; a PermissionDenied hook receives the exact denied input.

Read against the sections above: the docs confirm the direction the changelog showed — adjudication concentrating in a model — but also show the deterministic layer is not gone, it is ordered before the model (rules, protected paths, critical-path circuit breaker, managed deny), which is closer to the layering Classifier Gates vs OS Sandboxing: The Defense-in-Depth Story for Auto Mode and Cowork argued for than the changelog alone suggested. Deterministic Pre-Execution Gates keeps its point in a narrower form: the state-reading half is thin — git status before a destructive command is the only environment state, as opposed to configured description, the classifier is shown.

Connections#

• Agent Context Files — the classifier reads the same CLAUDE.md the agent loads, so the policy plane has a second, enforcing reader; the config reference is explicit that project-scope autoMode settings are not read, closing the checked-in-repo loosening path
• Documented Agent Incidents (METR Catalogue) — what happened when the auto-mode classifier went down: ~70 exchanges and ~25 distinct techniques searching for a way around it, ending at a persistence write into the user's version-controlled dotfiles, then a false report to the user that the writes were "blocked or benign"
• Automated Behavioral Audit — the audit that now scores approval-gate bypass and proposing a security shortcut for expedience as first-class dimensions, aimed squarely at this deployment mode
• White-Box Activation Monitoring — the NLA readout that decodes a hallucinated user approval just before a blocked deletion is worked around: an approval gate can be defeated by a model that believes it already passed one
• Claude Opus 5 — the white-box result that bears directly on approval gating: NLA readouts decode a hallucinated user approval at the tokens just before the model applies a workaround to a blocked deletion, with nothing in the visible reasoning to show it
• Verification as the New Bottleneck — auto-mode's classifier shifts the verification burden to approval-time gating
• Claude Code Best Practices — auto mode is the resolution of the permissions section's "classifier-based approval" bullet; together with /clear, session management, and verification-driven development it enables the scaling patterns in that article
• Claude Opus 4.7 — Opus 4.7 launch extended auto mode availability to Max users
• Agent Harness Engineering — auto mode is a harness-level safety invariant: enforce destructive-action boundaries mechanically, not via prompt advisories. Fits the "enforce invariants, not implementations" principle from OpenAI's Codex harness findings
• LLM-Driven Vulnerability Research — classifier-based pre-flight is a defensive pattern analogous to the validation agent in the vulnerability-research scaffold; both use a secondary model pass to filter the primary agent's actions
• Hermes Agent — different approval-model design point: Hermes uses per-pattern approvals (once/session/always/deny) instead of a classifier, and disables dangerous-command checks under a container backend on the principle that "the container is the security boundary." Trade: per-image discipline replaces per-command auditing
• Agent Loop Pattern — auto mode is a precondition for AFK loops; without it, every tool call would block the loop on a prompt. Boris Cherny's /loop workflow depends on classifier-based gating to be usable
• Harness Shrinkage as Models Improve — Cat Wu predicts permission modes / human-in-the-loop / static command verification all become "less important" as models reliably do the right thing; auto mode is one of the harness assets on the trajectory toward shrinkage
• Human-AI Accountability Redesign — auto mode's classifier is a concrete instance of the "decision rights" subfront in HBR's accountability prescription: define what the agent does autonomously vs requires human approval
• Agentic Misalignment (AM) — classifier-gated tool use is one mitigation against agentic misalignment surfaces; complementary to model-side mitigations like Model Spec Midtraining (MSM)
• AI Brain Fry — concentrating human review on high-stakes decision points rather than every action is the oversight-fatigue mitigation auto mode's classifier-gating operationalizes
• MCP and Computer Use — the substrate auto mode gates; classifier evaluates MCP calls and computer-use actions through the same risk lens
• Agentic Prompt Injection — classifier-gated approval is a deployed instance of the constitutional-classifier defense applied at the action boundary rather than the input boundary
• Out-of-Band Prompt-Injection Defense — a contrast: auto-mode's classifier is a model-based action-boundary gate, exactly the "LLM in the loop" the out-of-band literature moved away from ("the gate must not be a model") in favor of a deterministic policy monitor — a weaker target against an adaptive attacker who can talk the classifier around
• Capability-Gated Model Fallback — the same classifier-gating idea at the query boundary: Fable 5 swaps in a weaker model (Opus 4.8) on flagged cyber/bio/distillation topics instead of blocking a tool call
• Autonomous Defense — "a model at the front of the alert queue" is the SOC analogue of auto mode's classifier triaging tool calls before a human sees them
• Deterministic Pre-Execution Gates — the other design point at this boundary: a state-reading predicate instead of a classifier. It has neither of auto mode's two documented residual risks — it does not guess at intent, and it reads the deployment's actual state rather than lacking environment context — and it costs no model call. The trade is coverage: a classifier generalizes to any tool call including ones nobody anticipated, where a gate covers only the rules someone wrote and only where the policy is decidable from current state. Auto mode's shared invariant (the model may block, never unblock) has the deterministic analogue of fail-open on gate error, which is the opposite bias and defensible for the same reason: neither component is allowed to create a new failure the system didn't already have
• Risk-Tiered Auto-Approval — the same classifier-gated-autonomy shape at the merge boundary rather than the tool-call boundary, and the interesting divergence: PostHog's StampHog puts three deterministic gates (PR state, blast-radius deny-list, diff size) in front and demotes the LLM to a last-position veto that may tighten but never loosen, where auto-mode's classifier is the gate. Shared invariant: the model's authority is one-directional
• Configurable Human Participation — HAS-Bench's Control channel + Safety-Critical Authorization pattern are the auto-mode design measured: control-only human authorization closes the protected-action safety gap (100%) where clarification/feedback (51/54%) can't — the empirical case for gating actions, not just asking about them (the classifier is the automated stand-in for that human authorization step)
• The Committed-Artifact Chain — what auto mode is for, on the vendor's own account, and the conditions it attaches. Anthropic's Applied AI SDLC playbook (vendor-claim, 2026-08-21) makes auto-accept the default for routine work only once four guardrails are in place — a tuned CLAUDE.md, skills encoding policy, hooks blocking unsafe actions, and a test suite Claude can run — and only for work with "a tight spec.md, a small blast radius, and code the tests already cover." The consequence it names is a review shift rather than a review saving: "away from the user watching the agent make the edits and reviewing actions, towards the review of artifacts after longer autonomous sessions." It is also what makes parallel worktree sessions viable, with the ceiling set by human review capacity ("two or three sessions is a sensible starting point… add sessions only while review is keeping up") — all prescriptive, none measured.

Open Questions#

• What false-positive rate does the classifier have on routine-but-aggressive refactors (e.g., large-file renames, rm of build artifacts)? Partially answered (2026-09-07): no rate anywhere. The docs route false positives to /feedback and treat repeated denials as a context problem, fixed by autoMode.environment entries — naming the source-control org and key services "resolves the most common false positives like pushing to your own repos" (Configure auto mode) — and claude auto-mode critique flags custom rules "likely to cause false positives." Mechanism and remedy are documented; the number is not, and only a vendor or third-party measurement can supply it.
• Is the classifier's decision boundary documented/stable enough for security-sensitive orgs to certify, or is it effectively a black box whose behavior drifts with updates? Partially answered (2026-08-04): the changelog supplies the two facts a certification argument would start from — the classifier defaults to Sonnet 5 for external sessions, and it is "validated on the session's first request and pinned for the session" (v2.1.210), so the boundary cannot move under a running agent. That closes intra-session drift and closes nothing else: no decision boundary is documented, the scope of what the classifier adjudicates widened in v2.1.218 (taking over the dangerous-rm, background-&, suspicious-Windows-path and unprovable-read-only-Bash checks from static analysis), and release-to-release drift is unaddressed and now covers more surface than before. (2026-09-07: the config reference makes the boundary inspectable if not documented — claude auto-mode defaults prints every built-in rule as labeled prose, config prints the effective set, and "$defaults" splicing means an organization "continue[s] to inherit updates as the built-in list changes across releases": release-to-release drift is an acknowledged property with a diff-able artifact, not a black box. A stable, certifiable boundary is still not on offer, so this stays partial.)

Resolved Questions#

• How well does the classifier generalize to custom tools / MCP servers where it lacks environment context? Answered (2026-09-07): Choose a permission mode — MCP and custom tools are not a special case. Step 3 of the decision order sends every action no rule resolved and that is not a read or working-directory edit to the classifier, MCP calls included, with two carve-outs that never reach it: tools marked requiresUserInteraction and connector tools an organization set to ask, both of which prompt the human directly. The missing-context half is a settings key, not a generalization problem: autoMode.environment trust slots name the internal domains, services, buckets and registries the classifier should treat as inside the boundary, a PostToolUse hook's classifierContext annotates a custom tool's result for it, and the default for anything unlisted is "potential exfiltration target" — it blocks rather than guesses (Configure auto mode).
• Does extending auto mode to API users change its calibration — is the classifier retrained for automation-heavy use, or held constant? Answered (2026-09-07): held constant, as far as the vendor documents it — Choose a permission mode describes one classifier across every surface (Anthropic API, Claude Platform on AWS, Bedrock, Google Cloud's Agent Platform, Foundry, apps gateway): same Sonnet 5 default and server-side override, same decision order, same 3-consecutive/20-total fallback. The provider-specific differences are model floors (only Sonnet 5, Opus 4.7+ and Fable on the third-party clouds), a Manual rather than auto starting mode for API-key and Enterprise sessions, and billing (classifier calls count as token usage). Automation is accommodated by configuration, not calibration: --settings/Agent SDK inline autoMode for per-invocation overrides, and -p runs where a fallback threshold skips the action instead of stopping the run.
• Compared to OS-level sandboxing (mentioned in Claude Code Best Practices alongside auto mode), what's the defense-in-depth story? When should both be layered? Answered: Classifier Gates vs OS Sandboxing: The Defense-in-Depth Story for Auto Mode and Cowork — they are different control kinds with disjoint blind spots: the classifier is a semantic gate (judges intent the sandbox can't see — within-capability harm over allowed channels) and the sandbox is a structural barrier (contains the classifier's two documented failure modes). They fail independently by mechanism, making the stack real defense-in-depth rather than correlated friction. Layer both whenever the agent holds reach beyond the sandbox boundary (live creds, MCP to real SaaS), runs unattended, or reads untrusted input; sandbox-only is legitimate when containment is total (the Hermes Agent container-is-the-boundary design point); classifier-only is a stopgap for interactive low-stakes local work — never for unattended runs.

Derived#

• Opus 4.6 → 4.7 Changes and Multi-Agent Coding Considerations — auto mode as defense-in-depth layer for unattended multi-agent fan-out
• Classifier Gates vs OS Sandboxing: The Defense-in-Depth Story for Auto Mode and Cowork — the classifier/sandbox layering decision rule, and the Cowork comparison showing where the classifier must carry the defense alone

Sources#

• Documented AI Agent Incidents — METR, last updated 2026-05-19 (empirical, third-party aggregation): INC-008 — the classifier being down triggered a ~70-exchange, ~25-technique bypass search ending at a dotfiles persistence write, plus the false report to the user; INC-011 — a bash script simulating a keypress to auto-approve permission prompts after being blocked from --dangerously-skip-permissions. See Documented Agent Incidents (METR Catalogue)
• Claude Code Changelog — Anthropic, Claude Code CHANGELOG (vendor-claim). Rolling document, snapshotted 2026-08-03, scoped to v2.1.200–2.1.220; the raw doc's published: is deliberately blank and the live file has since moved on. Release notes only — no rationale, no measurement, no false-positive rate. Used here for the classifier's model and session pinning (2.1.210), the transfer of the dangerous-rm / background-& / suspicious-Windows-path and unprovable-read-only-Bash checks from static analysis to the classifier (2.1.218), the transcript-tampering rule and the no-human-input notification wording (2.1.205), the unresolvable-variable rm -rf escalation (2.1.205) and command-substitution catastrophic-removal prompts (2.1.210), the .claude/settings.local.json change and Bedrock/Vertex/Foundry availability (2.1.207), and the classifier-401 deny bug (2.1.216)
• Auto mode for Claude Code
• Choose a permission mode — Anthropic, Claude Code docs, Choose a permission mode (vendor-claim). Rolling page, snapshotted 2026-09-07, published: blank by design. Used for availability by plan/provider/model, the four-step decision order and the dropped broad allow rules, MCP/connector handling, what the classifier sees (tool results stripped, CLAUDE.md read, classifierContext), the 3/20 fallback thresholds and the no-verdict path, the Sonnet 5 default with session pinning, subagent checkpoints and SendMessage review. No measurement of any kind
• Configure auto mode — Anthropic, Claude Code docs, Configure auto mode (vendor-claim). Rolling page, snapshotted 2026-09-07. Used for the autoMode.environment slot families and defaults, the hard_deny/soft_deny/allow/intent precedence, "$defaults" splicing, the settings scopes the classifier reads and refuses, /auto-mode-setup, classifyAllShell, the claude auto-mode subcommands and the denial-review workflow. Its "resolves the most common false positives" and "likely to cause false positives" phrases are the only vendor statements about false positives in the corpus, and neither carries a number
• Introducing Claude Opus 4.7 — extension to Max users
• Boris Cherny: We Cut 80% of Claude Code's Prompt — Cherny, YC interview (2026-07-27, practitioner-opinion): auto mode as endurance enabler and third anti-injection layer