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

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 time you use it, Claude Code shows a one-time warning you must accept.

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. As of v2.1.126 it also skips the write prompts on protected paths that other modes always gate: .git, .vscode, .idea, .husky, .cargo, .devcontainer, .yarn, .mvn, .claude (except .claude/worktrees), and files like .bashrc, .zshrc, .npmrc, .mcp.json, .claude.json.

Three things survive the flag:

• Explicit ask rules. Anything in your permissions.ask array still prompts.
• The circuit breaker. rm -rf / and rm -rf ~ still prompt.
• Deny rules. A deny at any settings level cannot be allowed by another level, including by bypass mode. Managed-settings denies are absolute.

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

Two supported ways around it:

• Run as a non-root user. The official devcontainer configuration creates and uses a non-root user for exactly this reason. In your own Dockerfile, add a user and switch to it before launching Claude Code (recipe below).
• Use a recognized sandbox. The root check is skipped automatically when Claude Code detects it is running inside a recognized sandbox environment.

Do not work around it with sudo claude ... wrappers. 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.

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)

Auto mode is the newest permission mode and the reason to reconsider the flag entirely. Instead of skipping review, a classifier reviews each tool call and auto-approves the ones that look safe; risky calls, including protected-path writes, get routed to it rather than waved through.

# At launch
claude --permission-mode auto

# Mid-session: cycle modes
# Shift+Tab

# As your default, in .claude/settings.json or ~/.claude/settings.json
{
  "permissions": {
    "defaultMode": "auto"
  }
}

The practical difference from bypass: auto mode can still block or prompt. The practical difference from default: it stops asking about the 93% you were going to approve anyway. Admins who want to forbid it set permissions.disableAutoMode to "disable" in managed settings, the same pattern used to block bypass 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,
    "filesystem": {
      "denyRead": ["~/.aws/credentials", "~/.ssh/"]
    },
    "network": {
      "allowedDomains": ["api.anthropic.com", "registry.npmjs.org"]
    }
  }
}

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 integration: the devcontainer config in github.com/anthropics/claude-code ships a default-deny firewall with domain whitelisting and runs as a non-root user, and the repo's examples/settings directory has starter settings.json files for common deployment scenarios.

Enabling It by Default, Mid-Session, and Outside the Terminal

By default

# 1. settings.json (user-wide or per project, gitignored local file)
{
  "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

Caveats: Claude Code on the web ignores defaultMode values of bypassPermissions and dontAsk from checked-in settings, so a repo cannot grant itself bypass. Managed settings can block the mode entirely (section below).

Mid-session

There is no slash command to jump straight into bypass from a normal session. Start with --allow-dangerously-skip-permissions and Shift+Tab into bypassPermissions when you want it; Shift+Tab out when you are done. A SessionEnd hook even has a dedicated bypass_permissions_disabled matcher, which tells you how deliberately Anthropic tracks entry and exit from this mode.

VS Code and the Desktop app

The VS Code extension reads the same settings files, so permissions.defaultMode is the equivalent there. The Claude Code Desktop app (macOS and Windows, no terminal) now supports skipping permissions as well.

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.
• --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. One billing note for subscription users: starting June 15, 2026, claude -p and Agent SDK usage draws from a separate monthly Agent SDK credit (Pro $20, Max 5x $100, Max 20x $200) instead of your interactive limits.

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 denyRead on ~/.ssh/ and ~/.aws/credentials, and container isolation for anything untrusted. Anthropic's own guardrails here are real but narrow: the root refusal, the rm -rf / circuit breaker, and the web platform ignoring checked-in bypass defaults. Everything else is your configuration.

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.
• permissions.disableAutoMode: "disable" blocks auto mode.
• 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