What is auto permission mode in Claude Code?

claude --permission-mode auto

The built-in starting mode on Pro, Max, and Team plans.

Answer

Auto mode replaces routine permission prompts with a review by a second model, the classifier, which blocks actions that escalate beyond your request, target unrecognized infrastructure, or look driven by hostile content Claude read. It is the built-in starting mode on Pro, Max, and Team plans, and requires a recent model. Explicit ask rules still prompt.

What it does

Auto mode moves the review step from you to a second model.

claude --permission-mode auto

That model, the classifier, reads each action before it runs and blocks anything that escalates beyond what you asked for, targets infrastructure it does not recognise, or looks like it came from hostile content Claude read somewhere.

It trusts your working directory and the git remotes that were configured when the session started. A remote added or repointed mid-session with git remote add or git remote set-url is not trusted.

On Pro, Max, and Team plans this is the mode interactive sessions start in, but not claude -p or the Agent SDK. That exception catches scripts: an automated run starts in Manual unless it passes --permission-mode auto itself. Enterprise plans and Console API keys start in Manual too, and so does every session on Bedrock, Google Cloud's Agent Platform, or Foundry, where the mode is in the cycle but not the starting point.

Explicit ask rules still force a prompt. So do connector tools your organisation set to ask, and MCP tools marked as requiring user interaction.

One consequence surprises people, because it looks like a rule breaking. Entering auto mode drops your broad allow rules, the ones that amount to arbitrary code execution:

blanket Bash(*) or PowerShell(*)
wildcarded interpreters such as Bash(python*)
package-manager run commands
Agent allow rules
Monitor allow rules, since Monitor commands run through the shell (v2.1.236 and later; before that they stayed in effect)

Narrow rules like Bash(npm test) carry over untouched, and the dropped ones come back when you leave the mode. The reasoning is that a rule granting everything would hand the classifier nothing to review.

The visible effect is backwards from what you expect: switching into the mode meant to reduce prompts can produce more of them, for exactly the commands your broadest rule used to cover. It is one of the reasons a mode appears not to have applied.

What your account needs

Availability and starting mode are two different things. The mode is available on every plan; what Pro, Max and Team also get is sessions that *start* in it. On the organisation plans, Team and Enterprise, it is on by default, and an administrator can turn it off for everyone.

The requirement that catches people out is the model, and it differs by provider:

Anthropic API and Claude Platform on AWS — Opus 4.6 or later, Sonnet 4.6 or later, or Fable 5
Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry, and signed-in Claude apps gateway requires Sonnet 5, Opus 4.7 or later, or Fable 5

Older models are not supported anywhere. If the mode is missing, this is the first thing to check.

When to use it

Auto mode suits sustained work where the direction is settled and the individual steps are not worth interrupting for:

a long task you have already scoped and want to run to completion
exploratory work in a repository you own, where the blast radius is local
sessions where prompt fatigue is the real risk, since approving without reading is worse than not being asked

When not to use it

Not for operations where being wrong is expensive and irreversible: production deploys, credential changes, anything touching infrastructure you cannot rebuild. The classifier catches a lot, but it is a judgement, not a boundary.

If what you want is a Claude that pushes work forward on its own but still asks before acting, that is a different setting entirely: the Proactive output style changes how Claude behaves, not who approves it.

How to check

Three messages mention auto mode, and they mean three different things. Only one of them is worth waiting out.

Auto mode is unavailable

The mode is missing from the Shift+Tab cycle, or a session that should have started in it started in Manual. Claude Code reports the mode as unavailable when the session fails a requirement, so check those first: the model, the provider, and whether any settings file, not only a managed one, sets disableAutoMode: "disable". The list is in What your account needs.

If every requirement holds, the cause is on Anthropic's side: auto mode was turned off server-side, or the server rejected it for your account. A session that received either answer keeps the mode off until it ends. Nothing you change inside that session brings it back. Start a new one later.

auto mode disabled by settings

A session that was running in auto mode dropped out of it, and the cycle lost the mode at the same moment. An administrator's disableAutoMode reached the running session from a managed source. This is policy, not a fault, and there is nothing to retry. Requires v2.1.251 or later; before that, a running session kept the mode until it ended.

`<model>` is temporarily unavailable, so auto mode cannot determine the safety of `<tool>`

Not about the mode at all. A classifier request failed, and rather than guess, Claude Code blocked the one action. Since v2.1.229 the message names the reason in parentheses: (rate-limited), (overloaded) and (server error) are transient, so retry the action. (timed out) or (connection failed) repeating means your connection, not Anthropic. On Amazon Bedrock the failure can repeat until the account can invoke the model the message names.

Example

Start a session in auto mode:

claude --permission-mode auto

Set it as your default in ~/.claude/settings.json:

{
  "permissions": {
    "defaultMode": "auto"
  }
}

The file matters. defaultMode: "auto" has no effect from .claude/settings.json or .claude/settings.local.json, and Claude Code then falls back to the built-in default, not to whatever ~/.claude/settings.json says. It has to be in your user settings. If a session starts in Manual mode with no error, that is usually why.

Administrators can remove the mode entirely through managed settings:

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

This drops auto from the Shift+Tab cycle, and a session started with --permission-mode auto starts in Manual instead. A session already in the mode leaves it when the setting arrives, with the message quoted in How to check.

Security considerations

The classifier is a model reviewing another model's actions. It shifts the failure mode rather than removing it: instead of you approving something you did not read, the classifier approves something it misjudged.

What it blocks by default includes actions that escalate beyond your request and anything reaching unrecognised infrastructure. What it cannot do is know which of your systems matter. A destructive command inside your own project, clearly implied by your own prompt, is exactly the kind of thing it lets through.

Two practical habits: commit before starting a long auto-mode session, and keep ask rules on the operations you always want to see. They still prompt here.

Common mistakes

Reading "auto" as "unattended". The mode reduces prompts. It does not make the session safe to leave running against anything you would not want rebuilt.

Putting defaultMode: "auto" in project settings. It is ignored there. Move it to ~/.claude/settings.json.

Retrying inside a session that lost the mode. Once a session has been told auto mode is unavailable, it stays that way until the session ends, whatever you fix meanwhile. A failed classifier check is the opposite case: it blocks one action, and retrying is exactly right. The two messages are told apart in How to check.

Expecting it on an older model. Sonnet 4.5, Opus 4.5, Haiku, and claude-3 models do not support auto mode on any provider.