Claude Code auto mode: what it does and how to use it

What is Claude Code auto mode?

The documentation calls it auto mode, and it is one value of the permission mode setting, written auto. Every Claude Code session runs in a permission mode, which decides what Claude can do without asking you first. In the default mode, called Manual in the interface, Claude stops and asks before most actions that edit files, run shell commands or reach the network. In auto mode, per the permission modes page, a second model, the classifier, reviews actions instead of you.

The classifier reviews each action before it runs. It blocks anything that escalates beyond your request, targets infrastructure it does not recognize, or appears driven by hostile content Claude read. Explicit ask rules you have written still force a prompt. The docs also say auto mode nudges Claude to keep working without stopping for clarifying questions, though Claude still asks when your prompt or a skill explicitly relies on it.

Two things auto mode is not. It is not the same as skipping permissions: that is bypassPermissions, a separate mode meant for isolated containers and VMs. And it is not a feature flag you have to hunt for. With Claude Code v2.1.283 or later, the docs say auto mode is the built-in starting permission mode for interactive terminal and VS Code sessions on every plan and provider. On earlier versions it was the built-in starting mode only on Pro, Max, Ultra and Team plans. Check your version with claude --version, and see how to update Claude Code if it is old.

How does auto mode relate to the other permission modes?

Auto mode is one of six modes. The table follows the docs' summary of what runs without a prompt in each. The permissions guide covers allow, ask and deny rules in depth; this page stays on the modes.

The table shows where auto mode sits: between accepting edits and removing every check. You still get a safety layer, but the layer is a model, not you. Deny rules block in every mode, bypass included. The docs also list actions that no mode auto-approves: tools matched by an explicit ask rule, tools that require user interaction, and recognized critical-path removals such as rm -rf / or rm -rf ~. Plan mode is covered in the guide to Claude Code plan mode.

Modes set a baseline and rules sit on top. While you are in auto mode, Claude Code drops some broad allow rules, among them Bash(*), wildcarded interpreters like Bash(python*), package-manager run commands and Agent allow rules. Narrow rules like Bash(npm test) stay in effect, and the dropped rules come back when you leave auto mode.

How do you turn auto mode on or off?

• During a session: press Shift+Tab to cycle modes. From auto, the first press switches to Manual, and the cycle then runs Manual, accept edits, plan, and back. The status bar shows ⏵⏵ auto mode on when it is active. Cycling to auto switches without a confirmation prompt, provided auto mode is available to you.
• From a permission prompt: in Manual and accept-edits modes, a Bash command's prompt gains a Yes, and switch to auto mode option when auto mode is available (v2.1.247 or later). Claude Code does not add it to prompts forced by one of your ask rules or by a hook.
• At startup: claude --permission-mode auto. The same flag works with -p for non-interactive runs.
• As a default: set permissions.defaultMode in ~/.claude/settings.json.

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

One trap from the docs: if you set defaultMode to auto in the project's .claude/settings.json or .claude/settings.local.json, the value does not take effect. Put it in ~/.claude/settings.json. The same goes for bypassPermissions. To go the other way, the example in the docs sets "defaultMode": "default" in the user file, and the next session shows ⏸ manual mode on in the status bar.

For a session that starts from claude -p or the Agent SDK, the built-in default is Manual, not auto, so pass the flag explicitly. On a cloud provider such as Amazon Bedrock, interactive sessions start in auto when no mode is set, but only with a supported model; otherwise they start in Manual.

What does the auto mode classifier block and allow?

The classifier trusts your working directory and the remotes configured for it when the session started. Everything else counts as external until you say otherwise. A remote added during the session with git remote add is not trusted. The docs publish both lists. This is a selection, not the whole list; run claude auto-mode defaults to print the full rules as JSON.

Pushes have a footnote. A push to a non-default branch whose name marks it as a deploy or publication target, such as production or gh-pages, is judged on its own terms, and a push's content is still checked against the other rules. If you want a human checkpoint before Claude pushes or opens pull requests while staying in auto mode, the docs recommend permissions.ask rules.

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

The docs caution that these rules match the command as written, so a push written another way, such as git -C <dir> push, does not match. For a checkpoint that inspects the full command text, they point to a PreToolUse hook; see the hooks guide.

What happens when auto mode blocks something?

Claude Code shows a notification and lists the action in /permissions under the Recently denied tab. Press r there to retry the action with a manual approval. Claude keeps working on whatever else it can do.

If the classifier blocks an action 3 times in a row, or 20 times in total, auto mode pauses and Claude Code resumes prompting you. Approving the prompted action resumes auto mode. The thresholds are not configurable. In a non-interactive -p run with no prompt to fall back to, the blocked action simply does not run and Claude continues.

You can lift a block by telling Claude. The classifier reads your approval, but the wording matters. Your message has to name the action and the specific thing that makes it dangerous, such as the branch of a force push. Saying only “you can force-push” clears nothing. The approval covers one action. To stop approving a routine pattern one action at a time, add it to autoMode.allow.

The reverse works too. If you say “don't push” or “wait until I review before deploying”, the classifier blocks matching actions even when the defaults would allow them. The docs add a limit: the classifier re-reads the transcript on each check, so context compaction can remove the message that stated the boundary. For a hard guarantee, add a deny rule.

Repeated blocks usually mean the classifier lacks context about your setup. Use /feedback to report false positives, or define trusted infrastructure as described below.

How do you configure auto mode for your own repos and tools?

By default only the working directory and the current repo's remotes are trusted. Pushing to your company's source-control organization or writing to a team bucket is blocked until you add it. For most setups, autoMode.environment is the only field you need. It tells the classifier which repos, buckets and domains are trusted.

Where you put it matters. The classifier reads autoMode from ~/.claude/settings.json, from managed settings, and from the --settings flag or Agent SDK inline JSON. It does not read autoMode from .claude/settings.json or .claude/settings.local.json, because a checked-in repository could otherwise inject its own allow rules. The classifier does read the same CLAUDE.md content Claude loads, so “never force push” in your CLAUDE.md steers both. See the CLAUDE.md guide.

claude auto-mode defaults   # built-in environment, allow, soft_deny and hard_deny rules as JSON
claude auto-mode config     # your settings applied on top of the defaults

For rules that must never be overridden, use permissions.deny. It blocks before the classifier is consulted. The docs call the classifier a second gate that runs after the permissions system. Inside a session, /permissions has an Auto mode tab for viewing and editing classifier rules.

Who can use auto mode, and why is it sometimes unavailable?

The docs list four requirements: any plan; on Team and Enterprise, an administrator has not turned it off; a supported model; and a supported provider. Providers include the Anthropic API, Claude Platform on AWS, Amazon Bedrock, Google Cloud's Agent Platform and Microsoft Foundry. Supported models depend on the provider and change as models ship, so read the current list on the permission modes page before assuming. The docs state that older models, including Sonnet 4.5, Opus 4.5, Haiku 4.5 and claude-3 models, are not supported on any provider.

If Claude Code reports auto mode as unavailable, check, in this order, the model, whether a settings file sets disableAutoMode, and your administrator. Administrators can turn it off by setting permissions.disableAutoMode to "disable" in managed settings, which removes auto from the Shift+Tab cycle. The docs also say Anthropic may turn auto mode off server-side or reject it for your account. A session that got either answer keeps auto mode off until it ends, so start a new session later.

Auto mode has a cost footprint. On Enterprise plans and on API and cloud-provider accounts, classifier calls count toward your token usage and add a round trip before execution. Reads and working-directory edits outside protected paths skip the classifier, so the overhead comes mainly from shell commands and network operations. The usage limits guide explains what counts toward plan limits.

When should you use auto mode, and when should you not?

Use it when you trust the direction of the task and the interruptions are the problem: a long refactor, a test-fix loop, a feature built from a clear prompt. Prompt fatigue is real, and a reviewer that says yes to every dialog is not reviewing anything. If you build things with Claude Code, ideas on the board come with a generated build prompt, which is a good fit for a hands-off first session.

1. Start with a clear prompt and a clean git state. Commit or stash first, so any change is easy to see and revert.
2. Keep ask rules for the actions you never want unattended, such as pushes and pull requests.
3. Use plan mode for unfamiliar code. The docs list exploring a codebase before changing it as plan mode's best use.
4. Use Manual mode for sensitive work. Production credentials, billing code and migrations deserve your own eyes.
5. Use `dontAsk` or a container for automation, not auto mode, when you need an exact allowlist or full isolation.

The permission mode is one layer. The Bash sandbox and outer isolation decide what an action can reach once it runs, and the docs say auto mode and the sandbox work independently and combine. For a tour of a first session, including mode switching, read the Claude Code tutorial.