claude --dangerously-skip-permissions (2026): What It Does, 5 Safer Setups & the New Auto Mode

What Changed in Claude Code Permissions (July to September 2026)

Dated from the Claude Code CHANGELOG, newest first. Only entries that change what bypass, auto, or Manual mode do.

The Command

# Interactive session, no permission prompts
claude --dangerously-skip-permissions

# One-shot headless task
claude --dangerously-skip-permissions -p "Fix all ESLint errors in src/"

# Make bypass available mid-session via Shift+Tab, without starting in it
claude --allow-dangerously-skip-permissions

The official CLI reference describes the flag as: "Skip permission prompts. Equivalent to --permission-mode bypassPermissions." There is no short alias and no -y. The first interactive launch shows a warning dialog; Claude Code saves your acceptance to user settings, and declining exits. In -p mode no dialog appears. A background session started with claude --bg --dangerously-skip-permissions is refused until you have accepted the dialog once interactively.

Two launch details people trip on. claude agents --dangerously-skip-permissions sets bypass as the default for sessions you dispatch from agent view. Since v2.1.199, claude --dangerously-skip-permissions daemon <subcommand> runs the subcommand instead of treating it as a prompt, which matters if you alias claude to include the flag.

What the Flag Actually Skips (and What It Cannot)

In bypass mode, every tool call runs without confirmation: file edits and writes, Bash commands, MCP tool calls, web fetches, subagent spawns. Allow rules stop mattering, because everything is already allowed. Since v2.1.126 (May 1, 2026) it also skips the write prompts on protected paths that every other mode gates: .git, .config/git, .vscode, .idea, .husky, .cargo, .devcontainer, .yarn, .mvn, .claude (except .claude/worktrees), and files like .gitconfig, .bashrc, .zshrc, .envrc, .npmrc, bunfig.toml, .pre-commit-config.yaml, .mcp.json, and .claude.json.

What survives the flag, per the permission modes docs:

• Deny rules. They block in every mode, including bypassPermissions. Managed-settings denies are absolute.
• Explicit ask rules. Anything in your permissions.ask array still prompts.
• The critical-path circuit breaker. rm or rmdir targeting the filesystem root, any top-level directory (/usr, /etc), your home directory, or your working directory and its parents still prompts. So does rm -rf "$DIR"/* with an unguarded variable, because an empty $DIR makes it rm -rf /*. Write "${DIR:?}" and it runs without a prompt. Hiding the removal in $(...) or a subshell doesn't skip the check.
• Tools that need a human. AskUserQuestion and MCP tools marked requiresUserInteraction.
• Outside reads, if you opted in. With permissions.blockReadsOutsideWorkingDirectories on (v2.1.257+), file-reading Bash commands outside the working directories prompt even in bypass mode.

In a -p run nobody can answer, so those remaining prompts become denials. Hooks also still fire: a PreToolUse hook that exits with code 2 blocks the tool call regardless of permission mode.

Why It Refuses to Run as Root or with sudo

On Linux and macOS, Claude Code refuses to start in bypass mode with root or sudo privileges. The exact error:

--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons

The check has been there since the 2.0 line. Issue #9184 reported it on v2.0.10 in October 2025, and it is still documented behavior today. Two supported ways around it:

• Run as a non-root user. The official dev container runs Claude Code as a non-root user for exactly this reason; the docs tell you to confirm remoteUser is a non-root account. In your own Dockerfile, add a user and switch to it before launching Claude Code (recipe below).
• Use a recognized sandbox. The docs say the root check is skipped automatically inside a recognized sandbox environment.

The undocumented escape hatch: IS_SANDBOX=1

What counts as "recognized" is not documented. A user in issue #58150 posted the check from the 2.1.139 bundle, reformatted:

if (process.platform !== "win32"
    && process.getuid() === 0
    && process.env.IS_SANDBOX !== "1"
    && process.env.CLAUDE_CODE_BUBBLEWRAP !== "1") {
  console.error("--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons");
  process.exit(1);
}

So IS_SANDBOX=1 claude --dangerously-skip-permissions starts as root, and several commenters on #9184 confirm it works. Three caveats. It is undocumented and can change in any release. Windows never runs the check. The VS Code extension had a worse failure mode: with allowDangerouslySkipPermissions set and running as root in code-server, it crashed with a bare "exited with code 1" (#36106). Use the variable only in a throwaway container you would be happy to delete.

Do not work around it with sudo claude ... wrappers on a real machine. An agent with root and no prompts can rewrite system paths, services, and other users' files. The check exists because that combination has no recovery story.

The 6 Claude Code Permission Modes

--dangerously-skip-permissions sets one of six modes. Switch between them with --permission-mode <mode> at launch, Shift+Tab during a session, or permissions.defaultMode in settings.json. The mode that asks before most actions is labeled Manual in the CLI, IDE extensions, and Desktop app. Its config value is still default, and since v2.1.200 manual works as an alias (claude --permission-mode manual).

Which mode a new terminal session starts in: the --permission-mode flag or --dangerously-skip-permissions wins, then permissions.defaultMode from settings, then the built-in default. The built-in default is auto on Pro, Max, and Team (v2.1.228+ on macOS, Linux, WSL; v2.1.233+ on native Windows). It is Manual for claude -p, the Agent SDK, Enterprise, Console API keys, Bedrock, Google Cloud's Agent Platform (Vertex AI), Foundry, Claude Platform on AWS, and Claude apps gateway sessions.

acceptEdits plus an allowlist covers most daily work: file changes flow, anything with side effects beyond the working directory still prompts. dontAsk is the inverse of bypass: instead of approving everything unlisted, it denies everything unlisted, which makes it the right mode for scripted runs where an unexpected tool call should fail loudly.

Auto Mode: The Official Middle Ground (March 2026, Now the Default)

Auto mode shipped in March 2026 and is the reason to reconsider the flag. Reads and edits inside your working directory run directly. Shell commands, network calls, and protected-path writes go to a separate classifier model, which blocks anything that escalates beyond your request, targets unrecognized infrastructure, or looks driven by hostile content Claude read. The classifier runs on Sonnet 5 by default, not on your /model pick.

Where the classifier runs changed on September 19, 2026 (v2.1.278). On Enterprise plans, Claude API accounts, Bedrock, Agent Platform (Vertex AI), Foundry, and LLM gateways, Claude Code now asks the server to review actions inside the session's normal model requests. There is no separate classifier charge. If the server can't review, Claude Code falls back to its own classifier calls and warns that those are billed. CLAUDE_CODE_AUTO_MODE_SERVER=0 opts out on Bedrock, Vertex, Foundry, and gateways. /status shows an "Auto mode server" row.

# At launch
claude --permission-mode auto

# Mid-session: cycle modes
# Shift+Tab

# As your default: ~/.claude/settings.json only.
# "auto" in a project's .claude/settings.json is ignored.
{
  "permissions": {
    "defaultMode": "auto"
  }
}

# Print the classifier's built-in block/allow rules as JSON
claude auto-mode defaults

Requirements: on the Anthropic API and Claude Platform on AWS, Opus 4.6 or later, Sonnet 4.6 or later, or a Fable model. On Bedrock, Agent Platform (Vertex AI), Foundry, and Claude apps gateway sessions, only Sonnet 5, Opus 4.7 or later, and Fable. There it sits in the Shift+Tab cycle with no opt-in since v2.1.207, but sessions still start in Manual. Haiku and the 4.5 models are not supported anywhere. If the classifier blocks 3 actions in a row or 20 in a session, auto mode pauses and Claude Code goes back to prompting.

Two numbers to hold next to each other. The 93% approval rate is why prompts are mostly noise. The 17% false-negative rate on real overeager actions, from the same Anthropic post, is why auto mode is not a sandbox. Johann Rehberger (Embrace The Red) got an Opus 5 auto-mode session to run a remote payload in up to 80% of runs (5 runs per variant) by splitting the attack into benign-looking steps. Anthropic closed the report as Informative, calling auto mode "a convenience feature backed by a best-effort classifier, not a security guarantee."

One interaction with this page's flag: the classifier blocks, by default, "launching an autonomous agent loop that runs without human approval or a sandbox, such as one started with --dangerously-skip-permissions." An auto-mode Claude cannot spawn a bypass-mode Claude on your host. Admins who want to forbid auto mode set permissions.disableAutoMode to "disable"; since v2.1.251 that also kicks already-running sessions out of auto mode.

5 Safer Setups, Ranked

Ranked by how much of the no-prompt speed you keep versus how much blast radius you give up:

The pattern across all five: the flag is never the security decision. Isolation, deny rules, or a classifier is. The flag only acknowledges a decision you made somewhere else.

settings.json: The Full Allowlist Schema

The permissions object in .claude/settings.json takes allow, deny, and ask arrays plus defaultMode and additionalDirectories. Evaluation order is deny, then ask, then allow; first match wins.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test *)",
      "Bash(git status)",
      "Bash(git diff *)",
      "Bash(git log *)",
      "Read(~/.zshrc)",
      "Edit(/src/**)",
      "WebFetch(domain:docs.anthropic.com)"
    ],
    "deny": [
      "Bash(curl *)",
      "Bash(wget *)",
      "Read(./.env)",
      "Read(./secrets/**)",
      "Edit(./.env)"
    ],
    "ask": [
      "Bash(git push *)",
      "Bash(npm publish *)"
    ],
    "additionalDirectories": ["../docs/"]
  }
}

• allow: auto-approves matching calls. No prompt.
• deny: blocks the call. A deny at any settings level cannot be allowed by another level, even managed-vs-local.
• ask: forces a prompt. These survive --dangerously-skip-permissions.

Settings merge across five scopes, highest precedence first: managed settings (cannot be overridden, even by CLI args), CLI arguments, .claude/settings.local.json (gitignored), .claude/settings.json (committed), ~/.claude/settings.json (user-wide). Permission rules merge rather than replace. Edits to permissions reload live; no restart needed. Full walkthrough: Claude Code settings.json guide.

Permission Rule Syntax

Rules are Tool or Tool(specifier).

Bash Rules

"Bash(npm run build)"   // exact command only
"Bash(npm run test *)"  // prefix match: test:unit, test:e2e, ...
"Bash(ls *)"            // word boundary: matches "ls -la", NOT "lsof"
"Bash(ls:*)"            // equivalent to "Bash(ls *)"
"Bash"                  // every Bash command

Read and Edit Rules

Gitignore-style paths with four anchors:

Other Tools

"WebFetch(domain:example.com)"        // scope web fetches to a domain
"mcp__puppeteer"                      // every tool from the puppeteer MCP server
"mcp__puppeteer__puppeteer_navigate"  // one specific MCP tool

For "allow all Bash except a blocklist," the documented pattern is: add "Bash" to allow and register a PreToolUse hook that rejects specific commands. Hook decisions never override deny rules, and a hook exiting 2 blocks a call even when an allow rule matches.

The /sandbox Command vs --dangerously-skip-permissions

These solve different problems. The docs draw the line precisely: /sandbox controls what a Bash command can access once it runs; --dangerously-skip-permissions controls whether tool calls run at all. In sandbox auto-allow mode, the OS-level boundary replaces the prompt; in bypass mode, nothing replaces it.

Mechanics: macOS uses Seatbelt, Linux and WSL2 use bubblewrap plus socat (sudo apt-get install bubblewrap socat). Native Windows and WSL1 are not supported. Default policy: write access only to the working directory and the session $TMPDIR, no network domains pre-allowed (first use prompts). Run /sandbox in a session to configure it; selections write to .claude/settings.local.json.

{
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false,
    "credentials": {
      "files": [
        { "path": "~/.aws/credentials", "mode": "deny" },
        { "path": "~/.ssh", "mode": "deny" }
      ],
      "envVars": [
        { "name": "GITHUB_TOKEN", "mode": "deny" },
        { "name": "NPM_TOKEN", "mode": "deny" }
      ]
    },
    "network": {
      "allowedDomains": ["api.anthropic.com", "registry.npmjs.org"]
    }
  }
}

Sandbox the whole process, not only Bash

/sandbox wraps Bash commands. File tools, MCP servers, and hooks run outside it, which is why it does not make bypass mode safe on its own. Anthropic's sandbox environments guide lists three boundaries it accepts for --dangerously-skip-permissions: a container, a VM, or the sandbox runtime. The runtime is the lightest. It applies the same Seatbelt or bubblewrap isolation to the entire Claude Code process:

# Configure writes + network first in ~/.srt-settings.json:
# allow writes to the project, ~/.claude, ~/.claude.json, /tmp
# allow api.anthropic.com (+ claude.ai, platform.claude.com for OAuth)
mkdir -p ~/.claude && echo '{}' > ~/.claude.json   # Linux: grants apply only to existing paths
npx @anthropic-ai/sandbox-runtime claude --dangerously-skip-permissions

Gotcha from the docs: without a valid ~/.srt-settings.json, the runtime still starts, blocks all network, and confines writes to paths like /tmp/claude. A clean start does not prove your settings loaded.

Docker Sandbox Recipe

The container approach for full bypass: non-root user (the flag refuses root), only the project directory mounted, network limited to what the task needs.

FROM node:22-slim

RUN npm install -g @anthropic-ai/claude-code \
    && apt-get update && apt-get install -y git \
    && rm -rf /var/lib/apt/lists/*

# Non-root user: required, the flag refuses to start as root
RUN useradd -m -s /bin/bash agent
USER agent
WORKDIR /work

ENTRYPOINT ["claude", "--dangerously-skip-permissions"]

docker build -t claude-yolo .

# Read-write project mount, nothing else from the host
docker run -it --rm \
  -e ANTHROPIC_API_KEY=$ANTHROPIC_API_KEY \
  -v "$(pwd)":/work \
  claude-yolo -p "Fix all TypeScript errors"

# Analysis-only: read-only mount, no network
docker run -it --rm \
  -e ANTHROPIC_API_KEY=$ANTHROPIC_API_KEY \
  -v "$(pwd)":/work:ro \
  --network=none \
  claude-yolo -p "Audit this codebase for injection vulnerabilities"

Prefer the official setup when you want VS Code or Codespaces integration. The quick path is the Dev Container Feature: add "ghcr.io/anthropics/devcontainer-features/claude-code:1.0": {} to the features block of .devcontainer/devcontainer.json. The :1.0 tag pins the install script, not Claude Code; the feature installs the latest release. The hardened path is the reference container in github.com/anthropics/claude-code/.devcontainer. Its init-firewall.sh limits outbound traffic to an allowlist, which needs the NET_ADMIN and NET_RAW capabilities. Set remoteUser to a non-root account or the flag will refuse to start.

Enabling Bypass Permissions by Default, Mid-Session, and Outside the Terminal

By default

# 1. ~/.claude/settings.json (user settings), a --settings file, or managed settings.
#    NOT .claude/settings.json or .claude/settings.local.json: ignored since v2.1.257
{
  "permissions": { "defaultMode": "bypassPermissions" }
}

# 2. Shell alias
alias yolo='claude --dangerously-skip-permissions'

# 3. Available but not active: adds bypass to the Shift+Tab cycle
claude --allow-dangerously-skip-permissions

Mid-session

You can't enter bypassPermissions from a session you started without it enabled. Start with --allow-dangerously-skip-permissions, which adds the mode to the Shift+Tab cycle without activating it, and switch when you want it. The cycle runs Manual, acceptEdits, plan, then bypassPermissions, then auto if available. The status bar shows ⏵⏵ bypass permissions on while it is active.

VS Code and the Desktop app

VS Code: turn on the Allow dangerously skip permissions extension setting. Without it, Bypass permissions does not appear in the mode indicator and a bypassPermissions default starts the conversation in Manual. To start every conversation in bypass, set claudeCode.initialPermissionMode to bypassPermissions in VS Code user settings. The extension never reads a project's .claude/settings.json for its starting mode.

Known bug: issue #91811 (still open on September 22, 2026) reports that the VS Code extension at 2.1.259 shows Bash prompts in bypass mode, mostly for cd <dir> && grep <relative path> shapes, while the standalone CLI with the same settings does not. If the extension prompts when it shouldn't, try the same task from the terminal CLI.

Desktop app: enable Allow bypass permissions mode in Desktop settings on Pro and Max. On Team and Enterprise, organization policy controls it.

Headless Mode and CI/CD

CI is where the flag is least controversial: no human is present to click approve, and the runner is ephemeral. Combine -p with either bypass or, better, a scoped tool list:

# Full bypass, capped turns
claude --dangerously-skip-permissions -p "Fix all ESLint errors in src/" --max-turns 5

# Tighter: pre-approve only what the job needs, deny-by-default everything else
claude -p "Fix all ESLint errors in src/" \
  --permission-mode dontAsk \
  --allowedTools "Read" "Edit" "Bash(npm run lint *)"

# Fast scripted calls: skip hooks, skills, plugins, MCP, CLAUDE.md discovery
claude --bare -p "Summarize the diff" --output-format json

• --allowedTools pre-approves tools; --disallowedTools adds deny rules (a bare name removes the tool from context, Bash(rm *) denies matching calls).
• --permission-mode works with -p, so dontAsk plus an allowlist gives you fail-loud automation instead of approve-everything automation. claude -p always starts in Manual unless you pass a mode; the Pro/Max/Team auto default does not apply to it.
• --permission-prompts none (v2.1.259+) tells print mode that nobody can answer, so prompts are denied instead of sent to an SDK host.
• --restricted (v2.1.248+, or CLAUDE_CODE_RESTRICTED=1) is the opposite of the flag: it removes command-running tools and WebFetch, keeps file tools inside the working directory, ignores user, project, and local settings files, and refuses bypassPermissions. Use it for eval harnesses on shared machines.
• --safe-mode (v2.1.169+, or CLAUDE_CODE_SAFE_MODE) is not a permission mode. It turns off CLAUDE.md, skills, plugins, hooks, and MCP servers for troubleshooting. Permissions work normally, so it adds no safety to a bypass run.
• --max-turns caps runaway loops; --output-format json or stream-json for parsing.

For GitHub Actions specifics (the anthropics/claude-code-action workflow, secrets, triggers), see the Claude Code GitHub Actions guide.

The Prompt Injection Attack Surface

Security researchers (Lasso among them) have flagged the flag as an attack vector, and the mechanics are simple: in bypass mode, anything that can put text in front of the model can execute code on your machine. The injection paths are concrete:

• Cloned repos. A malicious CLAUDE.md, README, or source comment can instruct the model. In default mode the resulting tool calls hit prompts; in bypass mode they run.
• Fetched web content. A page Claude reads via WebFetch can carry instructions. Scope fetches with WebFetch(domain:...) rules.
• MCP tool output. Bypass mode auto-approves MCP calls too, so a compromised or over-permissioned MCP server runs unattended.

The mitigations are the same three layers this page keeps returning to: deny rules for credentials (Read(./.env), Bash(cat .env*)), the OS sandbox with sandbox.credentials denying ~/.ssh and ~/.aws/credentials, and container isolation for anything untrusted. Anthropic's own guardrails here are real but narrow: the root refusal, the critical-path rm circuit breaker, and project settings no longer being able to switch bypass on. Everything else is your configuration.

Some attacks never touch the permission system, so no mode helps. Manifold Security's GitSpawn write-up (September 2026) showed a repo-supplied core.fsmonitor command in .git/config running on the host when Claude Code refreshed the git index, before the workspace-trust prompt was accepted. That variant was reported on 2.1.193 and fixed by 2.1.196. The point stands for any agent: the harness's own git calls run outside the sandbox and without a prompt. Open untrusted repos inside the container, not next to it.

One more failure mode that has nothing to do with attackers: in multi-hour bypass sessions, context rot degrades the model's judgment, and without prompts as checkpoints, degraded judgment executes immediately. Compact regularly (/compact or FlashCompact) on long autonomous runs.

Locking It Down for Teams

Managed settings sit above every other scope and cannot be overridden by CLI arguments, project settings, or user settings. Locations: /Library/Application Support/ClaudeCode/managed-settings.json (macOS), /etc/claude-code/managed-settings.json (Linux/WSL), C:\Program Files\ClaudeCode\managed-settings.json (Windows). Drop-in files in managed-settings.d/ merge alphabetically.

{
  "permissions": {
    "disableBypassPermissionsMode": "disable",
    "disableAutoMode": "disable",
    "deny": [
      "Read(./.env)",
      "Read(./secrets/**)",
      "Bash(curl *)"
    ]
  },
  "sandbox": {
    "enabled": true,
    "failIfUnavailable": true,
    "allowUnsandboxedCommands": false
  }
}

• permissions.disableBypassPermissionsMode: "disable" blocks --dangerously-skip-permissions and the bypassPermissions mode entirely, including subagent definitions that request it. It works from any scope, so a developer can put it in ~/.claude/settings.json to lock themselves out.
• permissions.disableAutoMode: "disable" blocks auto mode and makes Manual the built-in default.
• allowManagedHooksOnly: true blocks all user and project hooks, so guardrail hooks cannot be removed locally.
• Managed deny rules are absolute: no lower scope can re-allow them.

Frequently Asked Questions