claude --dangerously-skip-permissions: risks and safer modes

claude --dangerously-skip-permissions starts Claude Code in bypassPermissions mode, so tool calls run without permission prompts. Anthropic says to use it only in isolated environments such as containers or VMs, and points to auto mode, allow/deny rules and the Bash sandbox as the safer ways to cut prompts.

claude --dangerously-skip-permissions

Applies to: Claude Code 2.1.287 (CLI, VS Code, JetBrains, Desktop). Last checked: October 2, 2026.

On this page

What the flag does

The CLI reference describes --dangerously-skip-permissions as “Skip permission prompts. Equivalent to --permission-mode bypassPermissions.” These two commands start the same mode:

claude --dangerously-skip-permissions
claude --permission-mode bypassPermissions

According to the permission modes page, bypassPermissions “disables permission prompts and safety checks so tool calls execute immediately.” Since v2.1.126 that also covers writes to protected paths such as .git, .claude, .vscode, .bashrc and .mcp.json, which every other mode still guards.

Warning

Anthropic: “Only use this mode in isolated environments like containers, VMs, or dev containers without internet access, where Claude Code cannot damage your host system.” The docs add that bypassPermissions “offers no protection against prompt injection or unintended actions.” (Permission modes)

What still prompts in bypass mode

The permissions page lists what the mode does not skip:

• Explicit ask rules in your settings.
• Deny rules, which apply in every mode, including bypassPermissions.
• Connector tools your organization set to ask, and MCP tools marked requiresUserInteraction.
• Removals that target the filesystem root or home directory, such as rm -rf / and rm -rf ~, “as a circuit breaker against model error.”
• Cross-session messaging safeguards.

Allow rules have no effect in this mode, because everything else is already approved.

Root and sudo are refused

On Linux and macOS, Claude Code refuses to start in this mode as root or under sudo and prints (Permission modes):

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

The check is skipped inside a recognized sandbox. For unattended runs in a container, the docs point to the dev container setup, which runs Claude Code as a non-root user.

The --allow-dangerously-skip-permissions variant

--allow-dangerously-skip-permissions adds bypassPermissions to the Shift+Tab mode cycle without starting in it (CLI reference). You can begin in plan mode and switch later:

claude --permission-mode plan --allow-dangerously-skip-permissions

You cannot enter bypassPermissions mid-session unless the session was started with one of these flags or --permission-mode bypassPermissions.

Bypass in VS Code, Desktop and the web

• VS Code: the mode indicator shows “Bypass permissions” only after you turn on the Allow dangerously skip permissions toggle in the extension settings (Permission modes).
• Desktop: Auto and Bypass permissions appear in the mode selector only after you enable them in Desktop settings.
• Claude Code on the web: Bypass permissions is not available in cloud sessions, and defaultMode: "bypassPermissions" in a repository’s settings is ignored, “so a repository’s checked-in settings cannot start a cloud session in bypass-permissions mode.”

All permission modes compared

Claude Code has six modes. The table follows the permission modes page.

default is labeled Manual in the CLI and the IDE extensions, and manual is accepted as an alias from v2.1.200 (Permissions).

Switching modes

In the CLI, Shift+Tab cycles default → acceptEdits → plan. Optional modes slot in after plan. To start in a mode, pass the flag:

claude --permission-mode plan

To make a mode the default, set defaultMode in settings:

{
  "permissions": {
    "defaultMode": "acceptEdits"
  }
}

The same --permission-mode flag works with -p for non-interactive runs (Permission modes).

Auto mode: Anthropic’s suggested alternative to bypass

The docs’ answer to “fewer prompts without skipping checks” is auto mode: “For background safety checks with far fewer prompts, use auto mode instead” (Permission modes).

• Requires Claude Code v2.1.83 or later.
• A separate classifier model reviews actions before they run and blocks anything that escalates beyond your request, targets unrecognized infrastructure, or appears driven by hostile content Claude read.
• Blocked by default: curl | bash-style download-and-execute, sending sensitive data to external endpoints, production deploys and migrations, mass deletion on cloud storage, granting IAM or repo permissions, force push or pushing directly to main, among others.
• On Team and Enterprise, an admin must enable it first. On the Anthropic API it needs Claude Opus 4.6 or later, or Sonnet 4.6; on Bedrock, Vertex AI and Foundry only Opus 4.7 and Opus 4.8, with CLAUDE_CODE_ENABLE_AUTO_MODE set.
• If the classifier blocks an action 3 times in a row or 20 times in total, auto mode pauses and Claude Code goes back to prompting.

Warning

Anthropic calls auto mode “a research preview. It reduces prompts but does not guarantee safety. Use it for tasks where you trust the general direction, not as a replacement for review on sensitive operations.” (Permission modes)

Start in it with:

claude --permission-mode auto

Claude Code v2.1.142 and later ignore defaultMode: "auto" in .claude/settings.json and .claude/settings.local.json, “so a repository cannot grant itself auto mode.” Put it in ~/.claude/settings.json instead.

Allow and deny rules instead of skipping everything

Permission rules pre-approve or block specific tools and keep the rest of the prompts. Rules are evaluated deny first, then ask, then allow; the first match wins (Permissions). This example from the docs allows npm scripts and commits but blocks git push:

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git commit *)",
      "Bash(git * main)",
      "Bash(* --version)",
      "Bash(* --help *)"
    ],
    "deny": [
      "Bash(git push *)"
    ]
  }
}

Useful details from the same page:

• /permissions lists every rule and the settings.json file it comes from.
• A bare tool name such as Bash in deny removes the tool from Claude’s context entirely; a scoped rule like Bash(rm *) blocks only matching calls.
• Claude Code understands &&, ||, ; and |, so Bash(safe-cmd *) does not approve safe-cmd && other-cmd.
• Rules are enforced by Claude Code, not by the model. Instructions in CLAUDE.md shape what Claude tries but do not change what is allowed.
• From the command line, --allowedTools and --disallowedTools take the same rule syntax (CLI reference).

For CI that should never prompt and never exceed a fixed list, the docs point to dontAsk: it “auto-denies every tool call that would otherwise prompt,” so only permissions.allow rules and read-only Bash commands run.

claude --permission-mode dontAsk

Rules can also live in hooks: a PreToolUse hook can deny a call, force a prompt or skip it, but it cannot override a matching deny or ask rule. Hook-based setups are collected in the Skills & config guides.

Sandboxing: OS-level limits for Bash

The built-in Bash sandbox lets commands run without prompts inside a boundary the operating system enforces (Sandboxing). It runs on macOS (Seatbelt), Linux and WSL2; native Windows is not supported. Start it from a session:

/sandbox

On Linux and WSL2 it needs bubblewrap and socat:

sudo apt-get install bubblewrap socat

By default, sandboxed commands can write only to the working directory and the session temp directory, and a new network domain prompts the first time it is used. In auto-allow mode, sandboxed commands run without asking, while explicit deny rules, content-scoped ask rules such as Bash(git push *) and rm on critical paths still go through the normal flow. To extend write access to a specific path:

{
  "sandbox": {
    "enabled": true,
    "filesystem": {
      "allowWrite": ["~/.kube", "/tmp/build"]
    }
  }
}

When a command fails because of the sandbox, Claude may retry it outside the sandbox with the dangerouslyDisableSandbox parameter, and that retry goes through the regular permission flow. Setting "allowUnsandboxedCommands": false removes this escape hatch. sandbox.failIfUnavailable: true turns a missing sandbox into a hard failure instead of a warning.

The permissions page frames the two as layers: permission rules control which tools and paths Claude can use; the sandbox restricts what Bash commands and their child processes can reach “even if a prompt injection bypasses Claude’s decision-making.”

Dev containers: where bypass mode belongs

If you do need unattended runs, the documented place is a dev container. Add Claude Code with the Dev Container Feature in .devcontainer/devcontainer.json (Development containers):

{
  "image": "mcr.microsoft.com/devcontainers/base:ubuntu",
  "features": {
    "ghcr.io/anthropics/devcontainer-features/claude-code:1.0": {}
  }
}

The docs say that because the container runs Claude Code as a non-root user and confines command execution, “you can pass --dangerously-skip-permissions for unattended operation.” Confirm remoteUser is a non-root account, since the CLI rejects the flag as root.

Warning

“When executed with --dangerously-skip-permissions, dev containers do not prevent a malicious project from exfiltrating anything accessible inside the container, including the Claude Code credentials stored in ~/.claude.” Anthropic advises using dev containers only with trusted repositories, not mounting host secrets such as ~/.ssh, and pairing the flag with network egress restrictions. (Development containers)

The edits Claude makes in the bind-mounted workspace appear directly on your host. The anthropics/claude-code repository includes a reference container with an init-firewall.sh script that blocks outbound traffic except the domains Claude Code and your tools need.

How admins disable bypass mode

Set permissions.disableBypassPermissionsMode to "disable" in managed settings (Permissions):

{
  "permissions": {
    "disableBypassPermissionsMode": "disable"
  }
}

permissions.disableAutoMode works the same way for auto mode. Either key can sit in any settings file, but the docs note they are “most useful in managed settings where they can’t be overridden.” Managed settings can be delivered through MDM/OS-level policies, managed settings files, server-managed settings, or a self-hosted Claude apps gateway. On Linux, Claude Code reads /etc/claude-code/managed-settings.json at the highest precedence (Development containers). Because a Dockerfile in the repository can be edited by anyone with write access, the docs recommend server-managed settings or MDM for policy engineers cannot bypass.