Reference · Advanced · 15 min

Claude Code auto mode in depth: the classifier and its rules

How Claude Code's auto mode decides, what it blocks, how to teach it your environment with /auto-mode-setup or autoMode, and why to keep "$defaults".

Tested with Claude Code 2.1.316 · reviewed 2026-11-01

See the files on GitHub Free · MIT license

Summary

Since 2.1.283-2.1.284, interactive terminal and VS Code sessions start in auto mode if you haven't configured another mode. In this mode Claude doesn't ask permission for routine work: a separate classifier model reviews each action and blocks what is irreversible, destructive or leaves your environment.

This reference explains how it decides, what it blocks by default, how to teach it your infrastructure (/auto-mode-setup, autoMode.environment), how to tighten or loosen it (hard_deny, soft_deny, allow with "$defaults") and what to do with each block. For permission modes in general and allow, ask and deny rules, see the permissions recipe.

What it is and since when it's the default

Auto mode lets Claude work without the routine permission prompts. A separate classifier model reviews actions before they run and blocks anything that goes beyond what you asked for, targets infrastructure it doesn't recognize or looks driven by hostile content Claude read.

With 2.1.283 or later it's the built-in starting mode for interactive sessions in the terminal and VS Code, on every plan and provider (the CHANGELOG extends it to all of them in 2.1.284). The first time it starts this way it shows you a notice. It doesn't start in auto if you pass --permission-mode, if a settings file sets permissions.defaultMode, with claude -p or the Agent SDK (which start in Manual), or if something disables it.

In the status bar you see it as ⏵⏵ auto mode on; Shift+Tab moves you to Manual, then acceptEdits and plan. The docs warn: it reduces prompts but doesn't guarantee safety; use it for tasks whose general direction you trust.

Requirements and "auto mode unavailable"

It's available on every plan. On Team and Enterprise it comes enabled and an admin can turn it off with permissions.disableAutoMode: "disable" in managed settings. It needs a supported model:

Older models (Sonnet 4.5, Opus 4.5, Haiku 4.5, claude-3) don't work. If it says it's unavailable, check in this order:

1. The model.
2. Whether any settings file has disableAutoMode.
3. Your version (claude --version).

Anthropic can also switch it off temporarily from the server; in that case the session stays without auto until it ends, so open another one later. If you set "defaultMode": "auto" and it starts in Manual without an error, it's probably in .claude/settings.json or .claude/settings.local.json: it has no effect there. Move it to ~/.claude/settings.json.

How it decides each action (in order)

1. Your allow, ask and deny rules, with exceptions: writing to protected paths goes to the classifier even with an allow rule, no allow rule approves deleting critical paths such as rm -rf ~, and content ask rules like Bash(git push *) always ask you.
2. Reads and edits inside your working directory: approved automatically, except protected paths and the first read outside the working directories, which asks you.
3. Everything else goes to the classifier. If it blocks, Claude gets the reason, usually the rule name, such as [Data Exfiltration].

On entering auto, broad allow rules that amount to running any code (Bash(*), wildcard interpreters like Bash(python*), package manager run commands, Agent and Monitor rules) are suspended and restored when you leave; narrow ones like Bash(npm test) stay.

The classifier sees your messages, the tool calls and your CLAUDE.md, but not the tool results: that way a file or a web page with hidden instructions can't manipulate it directly.

What it blocks by default

The classifier trusts your working directory and the remotes the repo had configured when the session started; a remote added or changed during the session doesn't count. Everything else is external until you declare it. By default it blocks, among others:

• Downloading and running code (curl | bash).
• Sending sensitive data out.
• Production deploys and migrations, and mass deletions in the cloud.
• Granting IAM or repository permissions.
• Force push, git reset --hard, git checkout -- ., git clean -fd or git stash drop (it assumes you lose uncommitted work).
• git commit --amend on a commit it didn't create in this session or that's already pushed.
• terraform destroy, writing to a secrets manager or changing DNS and certificates.
• Merging a PR no human approved or disabling CI.
• Opening tunnels to the internet and printing a credential in the transcript.

On the other hand, by default it allows pushing to any branch of the repo you're working in, including the main one, and creating PRs; branches with deployment names like production or gh-pages are judged separately. In 2.1.316, claude auto-mode defaults lists 72 soft_deny rules, 16 allow and one hard_deny (Data Exfiltration).

You can inspect the classifier from the terminal:

# Rules that ship with Claude Code (in 2.1.316: 16 allow, 72 soft_deny, 1 hard_deny, 21 environment entries)
claude auto-mode defaults

# Read a specific rule by the start of its label
claude auto-mode defaults --label 'Git Destructive'

# What the classifier really uses: your settings + the defaults
claude auto-mode config

# AI feedback on YOUR rules (ambiguous, redundant, false positives)
claude auto-mode critique

# Back to defaults (deletes the autoMode block from ~/.claude/settings.json; asks for confirmation)
claude auto-mode reset

We tested --help, defaults, defaults --label and config; we didn't run critique or reset because they write to ~/.claude/settings.json or use your plan.

Teach it your environment: /auto-mode-setup and environment

Almost all false blocks come from the classifier not knowing your infrastructure: your GitHub organization, your internal domains, your bucket. There are two ways to teach it.

The guided one: /auto-mode-setup. 2.1.304 brings the version that also works on Bedrock, Vertex, Foundry, gateways and without telemetry. It reads the project's CLAUDE.md, README, config files and git remotes, your autoMode settings and permissions.allow, and the hosts, buckets and commands from your recent sessions (never your messages); optionally, the first word of your shell history and your repos' remotes. It shows you a draft you accept or discard as a whole and saves it to ~/.claude/settings.json. We didn't run it for this reference, because it writes to the user's settings.

The manual one: the autoMode.environment array, with sentences in prose, as you'd explain it to a new colleague ("Source control: github.com/my-org and all repos under it"). Start with your version control organization and your key services; add domains and buckets as blocks show up. Then run claude auto-mode config to check your entries are in.

hard_deny, soft_deny, allow and the danger of forgetting "$defaults"

Besides environment there are three lists, also in prose:

Explicit intent only counts if your message describes exactly the action and its target: "clean up the repo" doesn't authorize a force push; "force push this branch" does.

The critical part: if you write any of the lists without the literal string "$defaults", you replace the whole default list. A soft_deny without $defaults removes the rules for force push, curl | bash, production deploys and bypassing auto mode; a hard_deny without $defaults removes the data exfiltration rule. Always include $defaults unless you're going to own the whole list, copying it first with claude auto-mode defaults.

Example for ~/.claude/settings.json: your environment and rules, keeping the built-in ones:

{
  "autoMode": {
    "environment": [
      "$defaults",
      "Source control: github.com/my-org and all repos under it",
      "Trusted internal domains: api.staging.my-company.com",
      "Key internal services: GitHub Actions for CI"
    ],
    "soft_deny": [
      "$defaults",
      "Never run database migrations outside the migrations CLI, even against dev databases"
    ],
    "hard_deny": [
      "$defaults",
      "Never send repository contents to third-party code-review APIs"
    ]
  }
}

The classifier only reads autoMode from ~/.claude/settings.json, managed settings or --settings; never from .claude/settings.json or .claude/settings.local.json, so a repo can't slip in its own exceptions.

When it blocks: Recently denied, retries and the 3 and 20 limits

Each block shows up as a notice (for example bash denied by auto mode · [Data Exfiltration] · /permissions) and is listed in /permissions, Recently denied tab: highlight the action to read the command and press r to mark it for retry when you leave the dialog. The Auto mode tab of the same dialog (since 2.1.246) lets you view and edit rules and environment entries without opening files; what you change is saved to ~/.claude/settings.json.

If the classifier blocks 3 times in a row or 20 in total, auto mode pauses and goes back to asking you; approving the action resumes it. Those thresholds aren't configurable. Limits you state in the conversation ("don't push until I review") are respected too, but they aren't saved as rules and can be lost on compaction: for something lasting use ask or deny. For example, a human check before every push or PR, while staying in auto for everything else:

{
  "permissions": {
    "ask": [
      "Bash(git push *)",
      "Bash(gh pr create *)"
    ]
  }
}

Subagents, cost and the classifier model

With subagents, the classifier reviews three times: the task description before launching it, each action while it works (with the same rules as the main session; the permissionMode in its frontmatter is ignored) and its work and final report, which comes with a security warning if something looked wrong.

Cost: on Enterprise and with the Claude API, Bedrock, Vertex or Foundry, classifier calls count toward your token usage, except when the server does the review (Auto mode server row in /status). Reads and edits in your directory don't go through the classifier, so the extra spend comes from shell and network commands.

By default the classifier uses Claude Sonnet 5; since 2.1.302 you can pick another one with the CLAUDE_CODE_AUTO_MODE_MODEL variable. If you want it to review every shell command, even those approved by your narrow rules, turn on autoMode.classifyAllShell: more coverage at the cost of more latency. And remember: /rewind doesn't undo what was done with Bash; commit before long tasks.

Don't start in auto, or remove it entirely

These are two different files. To always start in Manual (you can still switch to auto with Shift+Tab), in ~/.claude/settings.json:

{
  "permissions": {
    "defaultMode": "default"
  }
}

To remove auto mode entirely (organizations, in managed settings):

{
  "permissions": {
    "disableAutoMode": "disable"
  }
}

And to review every shell command and turn off /auto-mode-setup:

{
  "autoMode": {
    "classifyAllShell": true
  },
  "skillOverrides": {
    "auto-mode-setup": "off"
  }
}

What we checked

On 1 Nov 2026 on Linux with Claude Code 2.1.316, without changing anything of the user's: claude auto-mode --help, claude auto-mode defaults (16 allow, 72 soft_deny, 1 hard_deny, 21 environment entries), defaults --label 'Git Destructive' and claude auto-mode config. An interactive session in a trusted folder started showing ⏵⏵ auto mode on (shift+tab to cycle). We didn't run /auto-mode-setup, the Auto mode tab in /permissions, or claude auto-mode critique or reset, and we didn't trigger a real classifier block. The rest comes from the official documentation: permission modes, auto mode configuration, commands, checkpointing and the CHANGELOG.

FAQ

How is it different from bypassPermissions?

Both run without asking, but auto sends non-routine actions through the classifier and respects deny and ask; bypassPermissions reviews nothing and should only be used in isolated containers or virtual machines.

Can I configure auto mode in the repo for the whole team?

No: defaultMode: "auto" and the autoMode block are ignored in .claude/settings.json and .claude/settings.local.json. Each person sets it in their ~/.claude/settings.json, or the organization in managed settings.

It says "auto mode unavailable for your plan", do I have to pay more?

According to the current docs it's on every plan. Check the model (older ones aren't supported), whether any settings file has disableAutoMode, and your version. If Anthropic switched it off on the server, try a new session later.

Plan mode or auto mode?

They don't compete: plan mode doesn't edit your code until you approve the plan; with auto mode available, commands the classifier approves also run in plan. The usual pattern is to plan in plan mode and execute in auto.

Does it protect me from prompt injection?

It helps: the classifier doesn't see tool results and a server-side probe flags suspicious content. But the docs are clear: it doesn't guarantee safety. For what must never happen, use deny rules or hooks.

Why does it block a git push to my own company repo?

If it's the repo you're working in, it allows it. If you push to another repo in your organization, the classifier doesn't recognize it: add "Source control: <your-org> and all repos under it" to autoMode.environment or run /auto-mode-setup.

The whole library