Claude Code auto mode vs --dangerously-skip-permissions

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:

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 pauses 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.

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.

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.

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.