Blog
Published: October 6, 2026
Auto mode lets Claude Code run tool calls without asking, after a classifier checks each one that is not a read or an edit inside your project. Since v2.1.284 (2026-09-28) it is where interactive sessions start when no mode is set. --dangerously-skip-permissions is different: it skips the classifier entirely. In both, deny rules and blocking hooks still hold. A “never” line in CLAUDE.md does not.
Checked against Claude Code 2.1.291 and the official docs on 2026-10-06. Permission behavior changes most weeks, so each fact below carries the version it arrived in.
What is auto mode in Claude Code? #
It is one of six permission modes. The permission modes docs describe what each one lets run without a prompt:
| Mode | Runs without asking |
|---|---|
default (shown as Manual) |
Reads only |
acceptEdits |
Reads, file edits, and common filesystem commands such as mkdir and mv |
plan |
Reads, plus commands the classifier approves when auto mode is available |
auto |
Everything, with a classifier checking in the background |
dontAsk |
Reads and pre-approved tools; anything that would prompt is denied |
bypassPermissions |
Everything. The docs say: isolated containers and VMs only |
Before 2.1.284 you had to choose auto mode. Now a terminal or VS Code session with no permissions.defaultMode starts in it, on every plan and provider, as long as the model supports it.
How does the auto mode classifier decide? #
In order, and the first match wins. Your allow, ask and deny rules decide first. Reads and edits inside the working directory are approved. Everything else goes to a classifier, which runs on Claude Sonnet 5 by default, not on the model you picked. On entry, auto mode also sets aside broad allow rules such as Bash(*) and package-manager run rules, so a wide rule you wrote for Manual does not wave commands past the classifier.
The classifier sees your messages, the tool calls, and your CLAUDE.md. Tool results are stripped, so text planted in a file or a web page cannot argue with it directly. By default it blocks things like curl | bash, force pushes, production deploys and migrations, git reset --hard, terraform destroy, and irreversibly deleting files that existed before the session. Run claude auto-mode defaults for the full list. A removal of a critical path such as rm -rf ~ skips the classifier and asks you in the terminal, with a two-minute countdown.
When it blocks, Claude is told the reason, and the call is listed under Recently denied in /permissions. After 3 blocks in a row or 20 in a session, auto mode s and prompting resumes.
How good is it? Anthropic's engineering write-up from March, when the classifier ran on Sonnet 4.6, measured a 0.4 percent false-positive rate on 10,000 real tool calls and a 17 percent miss rate on 52 real overeager actions, and called that 17 percent “the honest number”. The docs put it plainly: auto mode “does not guarantee safety”.
Auto mode vs --dangerously-skip-permissions: what is the difference? #
--dangerously-skip-permissions is the same as bypassPermissions mode. Auto mode reviews the risky calls. Bypass reviews nothing.
| Auto mode | --dangerously-skip-permissions | |
|---|---|---|
| Classifier | Checks every call that is not a read or a project edit | None |
Writes to .git ,.claude ,.zshrc ,.mcp.json |
Sent to the classifier | Allowed |
| Deny rules | Block | Block |
| A PreToolUse hook that denies or exits 2 | Blocks | Blocks |
rm -rf ~ and other critical paths |
Prompts, with a countdown | Prompts, with a countdown |
| Set from a repo’s .claude/settings.json | Ignored | Ignored, since 2.1.257 |
| Admin switch to turn it off | disableAutoMode: "disable" |
permissions.disableBypassPermissionsMode: "disable" |
The last two rows matter for a team. A cloned repo cannot switch either mode on for you, and an organization can switch either off for everyone through managed settings. Bypass also refuses to start as root or under sudo, unless it is inside a sandbox it recognizes.
How do you turn off auto mode? #
For yourself, set a default in ~/.claude/settings.json. Sessions then start in Manual, and the status bar says so:
{
"permissions": {
"defaultMode": "default"
}
}
For one session, start it with claude --permission-mode default. Inside a session, one press of Shift+Tab from auto switches to Manual. To remove auto mode altogether, set disableAutoMode to "disable" in any settings file, or in managed settings to do it for an organization: auto drops out of the Shift+Tab cycle, and --permission-mode auto starts in Manual. No environment variable does this any more. CLAUDE_CODE_ENABLE_AUTO_MODE has no effect, and the --enable-auto-mode flag went in 2.1.111.
What still stops a command in auto mode? #
Five things decide, and one thing people rely on does not.
| Control | What it does in auto mode | What can get past it |
|---|---|---|
| A deny rule | Blocks before the classifier is asked. Neither the classifier nor your own request overrides it | An installed mod, on a machine with no managed settings and no Team or Enterprise sign-in |
| A PreToolUse hook | Exit 2 or a JSON deny blocks; a hook that answers ask forces a prompt | Exit 1 and a timeout let the call through. A mod can approve past it unless the hook is in managed settings |
autoMode.hard_deny |
A rule written in prose that the classifier treats as absolute | Read only from user or managed settings, never from a repo. Judged by a model, so it is as good as the classifier |
| The classifier’s defaults | Blocks the risky categories listed above | About one overeager action in six, in Anthropic’s own test |
| A mod | Answers tool.check after rules and hooks, and its answer can replace theirs |
It is the thing that gets past the others, so review it like a dependency |
A “never” line in CLAUDE.md |
Context. The classifier reads it, so it steers, but Claude Code enforces nothing in it | Anything. It can also be lost when compaction drops the message that said it |
The last row is the common one. A study of 481 public CLAUDE.md files, arXiv:2608.23550, found that only 4 to 16 percent of the security rules written in them had a built-in control that would enforce them. If a sentence in your CLAUDE.md starts with “never”, it probably wants to be a deny rule or a hook, as CLAUDE.md vs skills vs hooks explains. How to write the hook is in the hooks guide.
Why it matters: three open issues report rm -rf runs that destroyed data, #93099 (57,235 files under a home folder), #95426 (about 600 GB, from a substitution that resolved to a drive root) and #99193 (about 116 GB, by a subagent). The reports do not agree on, or did not record, which mode was on, which is a lesson of its own. Since 2.1.281, an rm -rf on a substitution like the one in #95426 is no longer run unprompted in auto or bypass mode.
How do Codex and Cursor handle the same thing? #
All three now ship a reviewer that approves for you, and all three keep a flag that turns every check off.
| Claude Code | OpenAI Codex | Cursor | |
|---|---|---|---|
| Default | Auto mode, since 2.1.284 | The Auto preset: workspace-write sandbox, approval on request |
Auto-review, since Cursor 3.6 (2026-05-29) |
| Who reviews | A classifier on Claude Sonnet 5 | You, for what the sandbox does not allow, or auto_review , which fails closed |
A classifier on Gemini 3.5 Flash Lite, with Claude 4.5 Haiku as fallback |
| Everything on | --dangerously-skip-permissions |
--dangerously-bypass-approvals-and-sandbox , or--yolo |
Run Everything; in the CLI, --force or--yolo |
| Admin limit | Managed settings | allowed_approval_policies ,allowed_sandbox_modes |
Team settings take precedence |
Sources: OpenAI's approvals and security docs and Cursor's run modes docs, read 2026-10-06. Cursor's page says what applies to all of them: auto-review “is not a security boundary”. Codex is the one that starts inside an operating-system sandbox. Claude Code has one too, for Bash, but it is off until you turn it on with /sandbox.
Where Harbor fits #
A deny rule or a hook protects the machine it is written on. On a team, the command that cost someone a day usually ends up as a line in a review comment or a Slack thread, and from there on every laptop it is a sentence, not a control. Harbor guardrails close that gap: a rule turned on once reaches every machine on its next sync, and refuses the call in Claude Code, Codex and Cursor through their pre-tool-use hooks, telling the agent why, and what to run instead when the rule says. It covers shell commands, the file tools and, since harborloop 0.5.18, MCP tool calls, so a rule can stop the GitHub MCP server's merge_pull_request as well as gh pr merge. Each rule shows how often it fired.
Like any settings hook, it can be overruled by a mod you install yourself, and it is coordination rather than a security boundary. For prevention, use a sandbox.
Questions #
What is auto mode in Claude Code?
A permission mode in which Claude Code runs tool calls without asking, after a classifier (Claude Sonnet 5 by default) checks each one that is not a read or an edit inside your project. Since v2.1.284 (2026-09-28), interactive sessions start in auto mode when no permission mode is configured.
Is auto mode the same as --dangerously-skip-permissions?
No. --dangerously-skip-permissions is bypassPermissions mode: there is no classifier, and writes to protected paths such as .git and .claude are allowed. In both modes, deny rules and PreToolUse hooks that deny still block, and removing a critical path such as your home folder still asks first.
How do I turn off auto mode in Claude Code?
Set permissions.defaultMode to "default" in ~/.claude/settings.json, start a session with claude --permission-mode default, or press Shift+Tab once. To remove auto mode entirely, set disableAutoMode to "disable", in managed settings for a whole organization.
Does CLAUDE.md stop Claude Code from running a command in auto mode?
No. CLAUDE.md is context, not enforced configuration. The auto mode classifier reads it, so a "never" line steers it, but only a deny rule, a blocking PreToolUse hook, or an autoMode.hard_deny rule in your user or managed settings acts as a control.
Is Claude Code auto mode safe?
Anthropic's docs say it reduces permission prompts but does not guarantee safety. In Anthropic's March test the classifier missed 17 percent of 52 real overeager actions. Use deny rules and hooks for commands that must never run, and a sandbox when you need prevention.