Claude Code --dangerously-skip-permissions: When It's Safe

--dangerously-skip-permissions starts Claude Code in bypassPermissions mode: no permission prompts and no safety checks, so every tool call runs immediately. It is safe only inside an isolated environment such as a container or VM, run as a non-root user, with network egress limited. On your everyday laptop, use auto mode or the Bash sandbox instead.

This guide explains exactly what the flag skips, what still stops it, and the setup Anthropic’s docs recommend. Everything was checked against the official permission modes and dev container docs on 24 Oct 2026.

What the flag actually does

These two commands are equivalent:

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

In this mode Claude Code:

• runs every tool call without asking, including Bash commands, edits and web requests;
• allows writes to protected paths such as .git, .claude, .vscode, .husky, .bashrc, .zshrc, .npmrc and .mcp.json, which every other mode prompts for or denies;
• ignores your allow rules, because everything is already allowed;
• lets a sandboxed command connect to hosts outside your allowed domains, and lets Claude retry a failed command outside the sandbox without a prompt, unless you turned those off.

The first interactive launch shows a warning dialog. Accepting it writes skipDangerousModePermissionPrompt: true to ~/.claude/settings.json, so later sessions skip it. Non-interactive runs (claude -p) never show the dialog.

What still stops it

Bypass is not “anything goes”. These still apply:

Control	Behaviour in bypassPermissions
permissions.deny rules	Still block. Deny rules work in every mode
Explicit ask rules	Still prompt
PreToolUse hooks that deny or exit 2	Still block the tool call
Recognised rm/rmdir of critical paths (/, top-level directories, your home and working directory)	Still prompt, with a two-minute countdown in the terminal; unanswered prompts are denied
Tools that need user input, such as AskUserQuestion	Still prompt
Root or sudo on Linux and macOS	Claude Code refuses to start

The critical-path check only recognises rm and rmdir in forms it can parse. Anthropic’s docs warn it can miss commands, so it is no replacement for isolation. In a claude -p run, the few calls that would still prompt are denied instead.

Where it is (and isn’t) appropriate

Anthropic’s guidance is blunt: only use this mode in isolated environments like containers, VMs or dev containers without internet access, where Claude Code cannot damage your host. The docs also note that bypassPermissions offers no protection against prompt injection.

Situation	Use
Daily work on your own machine, fewer prompts	Auto mode (claude --permission-mode auto)
Fewer prompts without a classifier	Manual mode plus the Bash sandbox in auto-allow mode
CI job with a known set of commands	--permission-mode dontAsk plus --allowedTools, see headless mode
Long unattended run on code you trust	--dangerously-skip-permissions inside a container, VM or the sandbox runtime, as non-root
Untrusted repository	A dedicated VM or a cloud session, not bypass on your host

Note that the Bash sandbox alone is not enough for bypass runs: file tools, MCP servers and hooks run outside it. The official sandbox environments page says to run bypass sessions inside a container, a VM or the sandbox runtime so that those are inside the boundary too.

The safe setup: a dev container

Anthropic publishes a reference dev container in the anthropics/claude-code repository. It runs Claude Code as a non-root user and includes an init-firewall.sh script that limits outbound traffic to approved destinations. The docs say this combination supports running with --dangerously-skip-permissions for unattended work.

1. Copy the .devcontainer/ directory into your repository (or add the Claude Code Dev Container Feature to your own config).
2. Check remoteUser is a non-root account; the CLI rejects the flag as root.
3. Adjust the firewall allowlist to the hosts your build really needs.
4. Do not mount host secrets such as ~/.ssh or cloud credential files. Prefer repository-scoped, short-lived tokens.
5. Start Claude inside the container:

claude --dangerously-skip-permissions

Even then, the docs warn that a malicious project could exfiltrate anything inside the container, including the Claude Code credentials stored in ~/.claude. Use bypass with trusted repositories, review what changed afterwards, and keep everything in git.

Add guardrails that survive bypass

Because deny rules and hooks still fire, you can keep a few hard stops even in bypass mode:

{
  "permissions": {
    "deny": [
      "Read(./.env)",
      "Read(./.env.*)",
      "Read(./secrets/**)"
    ],
    "ask": [
      "Bash(git push *)"
    ]
  }
}

Remember that Bash(...) rules match the command text Claude writes, so Bash(curl *) does not stop /usr/bin/curl or sh -c 'curl ...'. For logic-based checks, add a PreToolUse hook that blocks dangerous commands. If you’d rather install a maintained set of guards than write your own, Kiln Guard ships one as a plugin; it still assumes you keep the container boundary.

Turn it off for a team

To stop anyone from using bypass mode, set this, ideally in managed settings so users cannot override it:

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

Claude Code then rejects --dangerously-skip-permissions, and a subagent defined with permissionMode: bypassPermissions falls back to the parent session’s mode. Two related facts: cloud sessions ignore defaultMode: "bypassPermissions" from settings files, and a session started with --restricted refuses bypass mode.

Related guides

• Claude Code permission modes: all six modes compared.
• Claude Code sandboxing: OS-level limits for shell commands.
• Claude Code security checklist: a rollout plan for teams.