Claude Code --dangerously-skip-permissions: what it skips and how to contain it

claude --dangerously-skip-permissions starts Claude Code in bypassPermissions mode, where tool calls run without permission prompts: shell commands, file edits, web fetches and MCP tool calls included. Deny rules and a short list of hard safety checks still apply, and Anthropic says to use the mode only in an isolated environment such as a container or VM, because it "offers no protection against prompt injection or unintended actions."

This guide was checked against Anthropic's permission modes documentation on 30 October 2026. Claude Code ships often, so treat the official docs as the reference. The last sections cover the part a container doesn't fix: MCP tools that act on remote services.

What the flag does

--dangerously-skip-permissions is equivalent to --permission-mode bypassPermissions. The CLI reference describes it as "Skip permission prompts." Ways to start in bypass mode or make it available:

# Start in bypass mode
claude --dangerously-skip-permissions

# The same thing, spelled as a mode
claude --permission-mode bypassPermissions

# Start in plan mode, with bypass available later in the Shift+Tab cycle
claude --permission-mode plan --allow-dangerously-skip-permissions

The last form isn't a safe middle ground. In interactive terminal sessions where bypass is available, Claude Code doesn't enforce plan mode's blocks: Claude is still told to plan without editing, but a file edit or shell command it attempts during planning runs without a prompt, and writes to protected paths are allowed. Explicit ask rules and critical-path rm removals still prompt.

You can also set "defaultMode": "bypassPermissions" under permissions, but only in user settings (~/.claude/settings.json), a --settings file or managed settings. A value in a repository's .claude/settings.json or .claude/settings.local.json doesn't take effect, and the session starts in Manual mode instead. A cloned repository can't put you in bypass mode.

You can't switch into bypass mode partway through a session that was started without it. A few more rules from the docs, as of October 2026:

• First-run warning. The first interactive session in this mode shows a dialog asking you to accept responsibility. Accepting writes "skipDangerousModePermissionPrompt": true to ~/.claude/settings.json; declining exits. Non-interactive runs (claude -p) show no dialog.
• No root. On Linux and macOS, Claude Code refuses to start in this mode as root or under sudo, with the error --dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons. The check is skipped inside a recognized sandbox.
• --restricted wins. A session started with --restricted refuses bypassPermissions.
• Cloud sessions ignore it. Claude Code on the web doesn't honor defaultMode: "bypassPermissions" from settings files, and Bypass permissions isn't offered there.
• Other apps need a toggle. In the VS Code extension the mode appears only after you turn on Allow dangerously skip permissions in the extension settings. In the desktop app it needs Allow bypass permissions mode on Pro, Max and Ultra plans, while organization policy controls it on Team and Enterprise.

What still applies in bypass mode

Bypass mode isn't "no rules." It removes prompts and most safety checks, but the docs list actions that no mode auto-approves:

Two things change in the other direction. Allow rules "have no effect in bypassPermissions", since there is nothing left to pre-approve. And writes to protected paths are allowed without asking. That list includes .git, .claude, .vscode, .devcontainer, shell startup files like .zshrc, and .mcp.json and .claude.json, the files that hold MCP server configuration. The other modes prompt for those writes, send them to a classifier or deny them, apart from plan mode in an interactive terminal session where bypass is available, which allows them too.

The critical-path prompt can be removed too. Setting CLAUDE_CODE_EVEN_MORE_DANGEROUSLY_SKIP_PERMISSIONS=1 in the launch environment (Claude Code v2.1.311 or later) lets those rm commands run unprompted in bypass mode. The docs warn that rm -rf ~ can then run without asking, so keep it to environments whose contents you can afford to lose.

Other ordinary tool calls generally run without permission prompts, including shell commands, file edits, web requests and the MCP tools the session has loaded; the linked documentation lists the remaining exceptions.

Run it inside a container

Anthropic's guidance is consistent across pages. The mode's warning reads: "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 common setups table lists claude -p "<prompt>" --dangerously-skip-permissions for fully unattended runs and marks a container, VM or the sandbox runtime as required, run as a non-root user.

The dev container guide is the practical version. Anthropic's reference container runs Claude Code as a non-root user and includes an init-firewall.sh script that limits outbound traffic to the destinations it allows. The same page is frank about what the container doesn't do:

• Claude "can still modify any file in the bind-mounted workspace, which appears directly on your host."
• A bypassed session can reach anything the container's network policy allows, so pair the flag with egress restrictions.
• 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 them only with trusted repositories and not mounting host secrets such as ~/.ssh or cloud credential files; prefer repository-scoped or short-lived tokens.

That last point matters for MCP. Any token you put in the container for an MCP server is readable by the agent and by anything a prompt injection convinces it to run.

Turn it off for an organization

Administrators block the mode with one key in managed settings:

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

The file-based location is /Library/Application Support/ClaudeCode/managed-settings.json on macOS, /etc/claude-code/managed-settings.json on Linux and WSL, and C:\Program Files\ClaudeCode\managed-settings.json on Windows. MDM policies and server-managed settings from the claude.ai admin console deliver the same keys. A user's own files and --settings can't override a managed key, apart from a few security-sensitive keys where Claude Code honors a stricter value from a lower level.

The key works from any settings file, so you can also put it in your own ~/.claude/settings.json to lock yourself out. If you don't want people using auto mode either, "disableAutoMode": "disable" sits beside it.

The dev container guide makes a related point: a setting baked into a Dockerfile in the repository can be changed by anyone with write access. For policy engineers can't edit away, use server-managed settings or MDM.

Auto mode as the alternative

Anthropic's own suggestion for fewer prompts is auto mode, not bypass. 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." Its default block list includes curl | bash, sending sensitive data to external endpoints, production deploys and migrations, force pushes, terraform destroy and granting IAM or repository permissions.

As of Claude Code v2.1.283, auto mode is the built-in starting mode for interactive terminal and VS Code sessions on every plan. It needs a supported model, and organizations can turn it off with disableAutoMode. Explicit ask rules still prompt, and actions your allow, ask or deny rules don't settle (apart from reads and edits inside the working directory) go to the classifier. Anthropic's warning applies: auto mode "reduces permission prompts but does not guarantee safety."

For CI, the docs suggest a third option: dontAsk mode with allow rules. Calls that would otherwise prompt are denied; pre-approved tools and actions that need no approval, such as reads inside the working directory, still run.

claude -p "run the test suite" --permission-mode dontAsk --allowedTools "Bash(npm test)" "Read"

The MCP risk once prompts are gone

In bypass mode, every MCP tool the session can see is callable without a prompt, unless a deny or ask rule names it or the server marks it requiresUserInteraction.

Claude Code loads servers from ~/.claude.json, from a project .mcp.json and from --mcp-config. When you're signed in with a claude.ai subscription, it also fetches the connectors you added in claude.ai. If your GitHub server exposes a tool that deletes repositories, or your issue tracker can close every ticket in a project, those tools are as available as search_issues.

A container protects your laptop's filesystem. It doesn't protect the remote service. An MCP call goes out to GitHub, Linear or your CRM with whatever credentials the server holds, and the effect happens there. If the container's firewall allows the MCP server's host, which it must for the server to work, the call goes through. This is the case MCP prompt injection is about: an issue body or web page the agent reads can steer it toward a write tool, and bypass mode removes the person who would have noticed.

Claude Code gives you some controls that still work in bypass mode:

• Load only the servers the job needs. claude -p "..." --strict-mcp-config --mcp-config ./ci-mcp.json ignores every other MCP configuration for that run. On a machine where an administrator has deployed a readable managed-mcp.json, Claude Code exits at startup instead.
• Remove MCP entirely when the task doesn't need it: --disallowedTools "mcp__*" takes every MCP tool out of Claude's context.
• Deny the dangerous tools. Deny rules still apply, so "deny": ["mcp__github__delete_*"] in the container's settings blocks those calls. The Claude Code permissions guide covers the rule syntax and file locations.

These all live in files and flags on the machine running the agent. They have to be repeated in every container image and CI job, and the upstream token still sits next to the agent.

Limit what the agent can see at the gateway

The other approach is to give the bypassed session a narrower view of your MCP servers in the first place. With Toolstile, the container's Claude Code talks to one remote MCP server, and Toolstile decides which upstream tools that agent gets.

Add the gateway and sign in once from an interactive session in the container. A claude -p run can't complete an OAuth sign-in, so the docs say to authorize first with /mcp or claude mcp login <name>:

claude mcp add --transport http toolstile 'https://toolstile.com/mcp'
claude mcp login toolstile

During sign-in you choose a workspace, and the session becomes its own agent there, separate from the Claude Code on your laptop. It starts with no access. In Access, set each tool for that agent:

• Allow the reads the job needs, such as searching issues or reading pull requests.
• Require approval for writes you want a person to check, such as creating an issue or commenting.
• Block destructive tools, or leave them ungranted.

Tools that aren't granted, or are blocked, never appear in the agent's tool list, and a call to one by name is refused. Toolstile checks current access on every call, so --dangerously-skip-permissions in the client has nothing to skip: the tool isn't there.

Require approval behaves differently from a Claude Code prompt. The call returns an approval-required result with a review link instead of running. In a team workspace an owner or admin reviews the exact arguments in Approvals and approves once; in a personal workspace, the connection owner does. The agent then retries the identical call. Bypass mode can't answer that approval, because it doesn't happen in the client.

A few more properties help with unattended agents:

• Upstream credentials stay in Toolstile. The container holds a Toolstile sign-in for one agent, not your GitHub or CRM tokens. If that sign-in leaks, it reaches only what the agent was granted, and Remove agent under Devices & agents cuts it off without touching the container.
• Tool review can hide a new or changed tool definition until an owner or admin accepts it, even under full access.
• Activity records the calls in one place.

See permissions for how grants, blocks and approvals combine, and the Claude Code setup guide for the full client steps.

What the gateway doesn't cover

Toolstile only sees MCP traffic sent to it. It does nothing about:

• Bash commands, file edits and writes to protected paths, which run inside the container.
• Web fetches and any network access the container allows.
• Local stdio MCP servers, and remote servers added to Claude Code directly or through claude.ai connectors rather than through the gateway.

For those, Anthropic's advice stands: a container or VM, a non-root user, an egress firewall, no host secrets mounted in, and managed settings for anything people shouldn't change. The gateway narrows the remote-tool part; the container narrows the rest.

To set this up, start with getting started. What is an MCP gateway? explains the model, and the MCP allowlist guide compares allowlists across clients.