Claude Code auto mode is the answer to permission-prompt fatigue. Instead of stopping to ask before every shell command and network call, a separate classifier model reviews each action in the background. It lets the safe ones run and blocks the dangerous ones, so you stay out of the loop until something actually looks risky.
It shipped as a research preview for Team users on March 24, 2026. Then, in the week of May 18-22, it landed on the Pro plan and picked up Sonnet 4.6 as a supported model. So if you bounced off it a couple of months ago because your plan or model wasn't eligible, that has probably changed.
Below is what auto mode actually does: the exact list of what it green-lights versus what it stops, how to switch it on, and where it sits relative to plan mode and --dangerously-skip-permissions.
What auto mode is
In default mode, Claude pauses and asks before it edits a file, runs a command, or hits the network. Auto mode removes that pause for the common case. A classifier model, separate from the model writing your code, inspects each proposed action and decides whether it can run. The permission-modes docs describe it as blocking "anything that escalates beyond your request, targets unrecognized infrastructure, or appears driven by hostile content Claude read."
The classifier does not see everything Claude sees. Per the docs, it reads your user messages, the tool calls themselves, and your CLAUDE.md, but tool results are stripped out before they reach it. So a poisoned file or a malicious web page can't talk the classifier into approving something, because the classifier never reads the page. A separate server-side probe scans incoming tool results for suspicious content before Claude reads them at all.
Anthropic's engineering writeup describes the classifier as two stages. A fast single-token filter decides yes-or-no on most actions, tuned to err toward blocking. When that filter flags something, a slower chain-of-thought pass takes over to cut down false positives. Anthropic reports the fast filter alone sits around an 8.5% false-positive rate, dropping to 0.4% once the reasoning stage kicks in. They also report a 17% false-negative rate on genuinely overeager actions, and that is the number worth keeping in mind. Auto mode is safer than running with no checks, but it is not a guarantee, and the docs label it a research preview in a warning box for exactly that reason.
What it auto-approves
The classifier trusts your working directory and the remotes your repo already has configured. Everything past that boundary counts as external until you tell it otherwise. Out of the box, these run without a prompt:
- Local file operations inside your working directory
- Installing dependencies that are already declared in your lock files or manifests
- Reading
.envand sending those credentials to their matching API - Read-only HTTP requests
- Pushing to the branch you started on, or one Claude created during the session
Reads and in-directory edits skip the classifier entirely, which keeps latency down. The round-trip cost shows up mainly on shell commands and network operations. Those are the things that actually need judgment.
What it blocks
Here is the default block list, straight from the docs:
- Downloading and executing code, like
curl | bash - Sending sensitive data to external endpoints
- Production deploys and migrations
- Mass deletion on cloud storage
- Granting IAM or repo permissions
- Modifying shared infrastructure
- Irreversibly destroying files that existed before the session started
- Force push, or pushing directly to
main
When the classifier blocks something, Claude gets the reason and tries a different approach. Each denial shows a notification and lands in /permissions under a "Recently denied" tab, where you can hit r to retry it with a manual approval.
There's a useful escape valve here. Boundaries you state in plain conversation count as block signals. Tell Claude "don't push until I review," and the classifier will block matching actions even when its default rules would have allowed them. That boundary holds until you lift it in a later message, and Claude deciding on its own that the condition was met does not lift it. The docs are honest about one caveat. Boundaries live in the transcript, not in a rules file, so context compaction can drop the message that set one. For anything you need to be load-bearing, write a deny rule instead.
There's also a fallback. Block three actions in a row, or twenty total in a session, and auto mode pauses itself and goes back to prompting you. Approve the next prompt and it resumes. Those thresholds aren't configurable. In headless mode with -p, repeated blocks abort the session outright, since nobody is around to approve anything.
How to turn it on
First, update. Auto mode needs Claude Code v2.1.83 or later.
claude update
In the CLI, press Shift+Tab to cycle permission modes. The default cycle is default → acceptEdits → plan. Auto mode slots in at the end of that cycle, but only once your account meets every requirement. The first time you land on it, you'll get an opt-in prompt. Accept it, or pick "No, don't ask again" to drop it from the cycle for good.
To start a session directly in auto mode:
claude --permission-mode auto
To make it your standing default, set it in your user settings at ~/.claude/settings.json:
{
"permissions": {
"defaultMode": "auto"
}
}
One gotcha is worth knowing. Claude Code ignores defaultMode: "auto" if it finds it in a project's .claude/settings.json or .claude/settings.local.json. A repo you cloned can't grant itself auto mode. It has to come from your own user settings.
The requirements, per the docs:
- Plan: all plans. On Team and Enterprise, an admin has to enable it in Claude Code admin settings before anyone can switch it on, and admins can lock it off entirely with
permissions.disableAutoMode. - Model: Opus 4.6 or later, or Sonnet 4.6. Older models, including Sonnet 4.5 and Opus 4.5, are not supported.
- Provider: Anthropic API only. Not on Bedrock, Vertex, or Foundry.
If Claude Code tells you auto mode is unavailable, one of those three is the reason, and it won't fix itself by waiting. A different message that names a model and says it "cannot determine the safety" of an action is something else. That one is a transient classifier hiccup, not an eligibility problem.
To leave auto mode, cycle past it with Shift+Tab or restart in a different mode.
How it compares to plan mode and skip-permissions
These three modes get conflated a lot, and they do genuinely different jobs.
Plan mode is the cautious end. Claude reads files and explores, writes up a plan, and makes no edits at all. Permission prompts still apply exactly as they would in default mode. Use it for understanding a codebase before you let anything touch it. The two connect nicely. When you approve a plan, one of the options is "Approve and start in auto mode," so you can review the strategy by hand and then hand off execution.
--dangerously-skip-permissions (the mode is bypassPermissions) is the reckless end. It disables prompts and the safety checks, full stop. No classifier, no review, nothing standing between Claude and your filesystem. The docs are blunt that it offers no protection against prompt injection and should only run in isolated containers or VMs with no internet access. On macOS and Linux it refuses to even start as root.
Auto mode sits between them. You get the no-prompt flow of skip-permissions, but with a classifier checking each action and a server-side probe screening tool outputs for injection. Anthropic frames it as the middle path, with longer uninterrupted runs and meaningfully less risk than skipping checks entirely. My honest read: auto mode is the right default for work where you trust the general direction but don't want to babysit every command, and skip-permissions stays quarantined to throwaway sandboxes. The bypassPermissions docs themselves point you at auto mode as the safer alternative.
One thing auto mode does on entry is easy to miss. It drops your broadest allow rules. Blanket Bash(*), wildcarded interpreters like Bash(python*), package-manager run commands, and Agent allow rules all get pulled, since they'd otherwise hand the model arbitrary code execution with no check. Narrow rules like Bash(npm test) carry over, and the dropped ones come back when you leave auto mode.
Where it fits
If you write skills or shared instructions for your team, auto mode is one more reason to make them precise. A vague skill that pushes Claude toward broad infrastructure actions will trip the classifier and stall the session. A tight one keeps the work inside the auto-approved lane. (Knack, at getknack.ai, turns a short interview into exactly that kind of scoped SKILL.md.)
Turn it on for the next refactor or test-fixing pass, the kind of task where you already know what you want and just don't want to approve forty file edits one at a time. Keep default or plan mode for anything touching production. And leave --dangerously-skip-permissions where it belongs, inside a container that can't hurt you.
Word count: ~1,550
URLs cited: