Auto Mode: How the Classifier Works

A Separate Reviewer for Every Action

Auto mode does not remove safety checks — it replaces per-action human review with a separate classifier model that reviews each tool call before it executes. The classifier runs server-side on a model independent of your /model selection, reads from a portion of your transcript, and returns a decision: allow, or block with a reason. Claude receives the reason for any block and can try an alternative approach.

This design means auto mode is not "trust Claude completely." It is "trust a behavioral reviewer to catch dangerous actions so you don't have to review every individual command." The classifier makes mistakes in both directions — false positives that block legitimate actions, and false negatives that allow risky ones. Understanding how it works helps you configure it correctly and interpret its decisions.

The Four-Step Decision Chain

Every action in auto mode passes through four gates in order. The first gate to resolve the action wins:

1. Permission rules: Allow and deny rules from your settings evaluate first. A matching deny rule blocks immediately; a matching allow rule approves immediately. Protected-path writes skip allow rules and go to the classifier regardless.
2. Read-only / cwd edits: Read-only Bash commands and file edits inside the working directory are auto-approved without going to the classifier, except for protected-path writes.
3. Classifier: Everything else goes to the classifier. The classifier reads user messages and tool calls — tool results are stripped, so hostile content in a file Claude read cannot manipulate the classifier directly.
4. Fallback: If the classifier blocks an action, Claude receives the reason and tries an alternative. After 3 consecutive blocks or 20 total blocks in a session, auto mode pauses and Claude Code resumes prompting.

When auto mode activates, broad allow rules that would grant arbitrary code execution are dropped: Bash(*), wildcarded interpreters like Bash(python*), package-manager run commands, and Agent allow rules. Narrow rules like Bash(npm test) carry over. Dropped rules restore when you leave auto mode.

What the Classifier Blocks by Default

The classifier maintains a built-in block list that covers the most consequential unrecoverable actions:

• Downloading and executing code (curl | bash patterns)
• Sending sensitive data to external endpoints
• Production deploys and database migrations
• Mass deletion on cloud storage
• Granting IAM or repository permissions
• Force push to any branch
• IaC destroy commands (terraform/pulumi/cdk/terragrunt destroy)
• Destructive git commands: git reset --hard, git checkout -- ., git restore ., git stash drop
• Amending a commit that was not created in the current session or was already pushed
• Writing to secret managers, changing DNS records or TLS certificates
• Merging a PR without human approval, approving Claude's own PRs, disabling CI checks
• Toggling, ramping, or deleting production feature flags

What is allowed by default: local file operations in the working directory, installing from lock files and manifests, read-only HTTP requests, pushing to the branch you started on or one Claude created this session.

Conversation Boundaries and Their Limits

The classifier treats explicit boundaries you state in conversation as block signals. If you tell Claude "don't push" or "wait until I review before deploying," the classifier blocks matching actions even when they would otherwise be allowed. A boundary stays in force until you lift it in a later message.

Critical limitation: Conversation boundaries are not stored as rules. The classifier re-reads them from the transcript on each check. If context compaction removes the message where you stated the boundary — which happens automatically as long sessions grow — the boundary is silently lost and matching actions may proceed. For guarantees that survive compaction, add a permissions.deny rule instead. A deny rule is evaluated before the classifier and is not affected by transcript length.

Two Error Types: Permanent vs Transient

When auto mode appears unavailable, two distinct error messages tell you why:

• \"Auto mode unavailable\": A permanent requirement is unmet. Check the model (Haiku, Sonnet 4.5, and all claude-3 models are not supported on any provider), the plan, and for Team/Enterprise accounts, whether an Owner has enabled it in admin settings. On Bedrock, GCP, Foundry, and signed-in Claude apps gateway sessions, also check whether CLAUDE_CODE_ENABLE_AUTO_MODE=1 is set.
• \"Cannot determine the safety of an action\": A transient classifier outage. This is not a permanent block. The classifier is temporarily unavailable for that specific action. Retry the action or wait briefly and try again — this is not a signal to disable auto mode or change your configuration.

Repositories Cannot Grant Themselves Auto Mode

A project's .claude/settings.json or .claude/settings.local.json cannot activate auto mode. Claude Code silently ignores defaultMode: \"auto\" in those files. This is a deliberate security gate: a repository you clone cannot elevate its own permission baseline to auto mode. Auto mode can only be activated from ~/.claude/settings.json (user settings) or managed settings, both of which are files you control, not repository-supplied files.

If you set defaultMode: \"auto\" in .claude/settings.json and the session starts in Manual mode with no error, the setting is being ignored. Move it to ~/.claude/settings.json.

How Auto Mode Reviews Subagents

When Claude spawns a subagent, the classifier applies checks at three points: before the subagent starts (evaluating the delegated task description), during execution (each of the subagent's actions goes through the same classifier rules as the parent), and when the subagent finishes (a review of its full action history). A suspicious task description is blocked at spawn time before the subagent runs a single action. Any permissionMode in a subagent's frontmatter is ignored — the parent session's mode applies.