claude --dangerously-skip-permissions: what it does, the risks, and safer options

claude --dangerously-skip-permissions starts Claude Code in bypassPermissions mode: every tool call runs without asking, file edits and shell commands alike, including writes to .git and .claude. Anthropic's docs say to run it only inside a container, a VM or the sandbox runtime. On your own machine, auto mode removes most prompts and keeps a check in front of each action.

What --dangerously-skip-permissions turns off

In Manual mode (default in config) Claude Code asks before it edits a file or runs a command it has not been allowed to run; auto mode hands that question to a classifier. The flag removes both. The CLI reference calls it the equivalent of --permission-mode bypassPermissions, and the permission-modes page defines the mode as one that "disables permission prompts and safety checks so tool calls execute immediately, including writes to protected paths".

Protected paths are the files that change how your tools behave: .git, .vscode, .idea, .husky, .devcontainer, most of .claude, and files such as .bashrc, .zshrc, .gitconfig, .npmrc and .mcp.json. Every other mode asks before writing them, sends them to auto mode's classifier, or denies them (dontAsk); this one writes them.

In an interactive terminal session where bypass is available, plan mode's blocks are not enforced either: Claude is told to plan, but an edit it tries runs without a prompt.

How to turn bypass mode on

• As your default: "permissions": {"defaultMode": "bypassPermissions"} in ~/.claude/settings.json. The same line in a project's .claude/settings.json is ignored and the session starts in Manual, so a cloned repository cannot switch it on for you.
• Mid-session: Shift+Tab cycles Manual → accept edits → plan, then bypass and auto when they are available. Bypass is in the cycle only if the session started with one of the flags above; a session started without it cannot enter it.
• VS Code: turn on Allow dangerously skip permissions in the extension's settings, then pick Bypass permissions from the mode indicator.
• Desktop app: the Allow bypass permissions mode toggle in its settings on Pro and Max; on Team and Enterprise, your organization's policy.
• Not available: cloud sessions on claude.ai/code, Remote Control sessions from the app, and sessions started with --restricted.

The first interactive run shows a warning; declining exits. In the dialog Caprock read, the selected answer is No, exit: pressing Enter without reading ends the session. Choose Yes, I accept with the arrow keys. Accepting writes "skipDangerousModePermissionPrompt": true to ~/.claude/settings.json, and later runs skip the dialog. With -p there is no dialog; a background session (claude --bg) is refused until you have accepted it once.

What still asks, even in bypass mode

• Deny rules. "Deny rules block in every mode, including bypassPermissions." Allow rules, on the other hand, do nothing here.
• Ask rules you wrote explicitly.
• Removing a critical path: rm or rmdir on the filesystem root, a top-level folder like /usr, your home folder, the working directory or its parents. The prompt counts down two minutes and denies the command if nobody answers, so an unattended session keeps going; after three unanswered prompts, later ones are denied at once.
• Questions Claude asks you, and MCP tools marked as needing a person.
• A hook that denies the call. A PreToolUse hook runs in every mode; see Claude Code hooks.
• Reads outside the working directories, when permissions.blockReadsOutsideWorkingDirectories is on in any settings file, a repository's included. While on, Read, Grep and Glob are refused outside them, and file-reading Bash commands ask in every mode, bypass included. --add-dir or /add-dir makes a folder a working directory; removing the setting ends it.

The risks Anthropic names

Claude reads files, web pages and command output while it works. Text in any of them can ask it to do something else: read ~/.ssh, post a token somewhere, rewrite a hook. With prompts on, you see that request before it runs. With them off, nothing stands between the instruction and the action except deny rules, hooks and whatever boundary the process runs in.

The second risk is ordinary mistakes at speed: a migration run against the wrong database, a git push --force, a config file rewritten.

How to run it safely

Anthropic's sandbox guide is direct: "Always run --dangerously-skip-permissions sessions inside a container, a VM, or the sandbox runtime", so that file tools, MCP servers and hooks are inside the boundary too.

• The sandbox runtime wraps the whole Claude Code process in the same Seatbelt (macOS) or bubblewrap (Linux, WSL2) isolation the Bash sandbox uses, with no Docker. It is a beta research preview. Configure ~/.srt-settings.json first — writable project folder, ~/.claude, ~/.claude.json, the temp folder, the API domains — then install it with npm install -g @anthropic-ai/sandbox-runtime and run srt claude.
• A dev container is Anthropic's reference setup, runs Claude Code as a non-root user, and can restrict outbound traffic. It does not stop a malicious project from exfiltrating what is inside it, including the credentials in ~/.claude, and the bind-mounted workspace is your real folder on the host.
• A VM, or a cloud session, for a repository you do not trust.
• Not enough on its own: /sandbox. It confines shell commands only; Claude's own Read, Edit and WebFetch tools, MCP servers and hooks run on the host. In bypass mode, a sandboxed command's retry outside the sandbox also runs without a prompt, unless you add an ask rule for Bash(dangerouslyDisableSandbox:true), and a sandboxed command reaches a host outside your allowed domains without a prompt, unless sandbox.network.strictAllowlist (or a managed allowManagedDomainsOnly) is on.
• Not a sandbox: a git worktree. It is a separate checkout of the same repository on the same machine, with the same access.

Then narrow what a bypassed run can do:

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

A Bash deny rule matches the command as Claude usually writes it, not every way to run the program: Bash(git push *) stops git push origin main and not git -C . push origin main. Anthropic says plainly it "isn't a security boundary": for enforcement use the sandbox, or a PreToolUse hook that inspects the full command.

Why it fails as root

On Linux and macOS, Claude Code refuses to start in this mode as root or under sudo, with --dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons. Run it as a normal user, as Anthropic's dev container does. Inside a sandbox Claude Code recognises, the check is skipped.

Safer options, from fewest prompts to most

Auto mode is what most people reaching for the flag want (the whole mode, with what still asks, is in Claude Code auto mode). In Anthropic's words, "a separate classifier model reviews actions before they run, blocking anything that escalates beyond your request, targets unrecognized infrastructure, or appears driven by hostile content Claude read." It is available on all plans, needs a recent model (on Anthropic's API, Opus 4.6 or later, Sonnet 4.6 or later, Haiku 5.5 or a Fable model), and from Claude Code v2.1.283 it is the mode an interactive session starts in. Anthropic is plain that it "does not guarantee safety"; it is far more than bypass mode gives you.

Allow rules remove the prompts you see most. Put the commands you trust in .claude/settings.json:

{
  "permissions": {
    "allow": ["Bash(npm run *)", "Bash(git diff *)", "Bash(git log *)"],
    "deny": ["Bash(git push *)", "Read(./.env)"]
  }
}

Deny is checked first, then ask, then allow. /permissions lists every rule and the file it came from.

The Bash sandbox (/sandbox) runs shell commands under macOS Seatbelt, or bubblewrap on Linux and WSL2. Commands can write only to the working folder and temp, and reach only the domains you allow. Sandboxed commands run without a prompt by default (sandbox.autoAllowBashIfSandboxed). On native Windows commands run unsandboxed; use WSL2 or a container.

Running it unattended, the careful way

For CI or a script, list exactly what the run may do instead of skipping everything. dontAsk denies whatever is not on the list:

# A fixed list of allowed tools; the rest is denied
claude -p "run the tests and fix failures" \
  --permission-mode dontAsk \
  --allowedTools "Bash(npm test)" "Read" "Edit"

# Or let the classifier decide, with no prompts claude -p "fix the failing test" \ --permission-mode auto

# Bypass only inside a container or VM, # as a normal user claude -p "fix the failing test" \ --dangerously-skip-permissions ```

In a -p run the few calls that would still prompt are denied instead.

Turn it off for yourself or a team

Set permissions.disableBypassPermissionsMode to "disable". Claude Code then rejects the flag, and a subagent's permissionMode: bypassPermissions is ignored. It works in any settings file — a user can lock themselves out — and in managed settings nobody can override it. permissions.disableAutoMode does the same for auto mode.

Switch modes and see what a bypassed session did

Caprock's session panel and session header carry a chip with the mode a Claude Code session runs in — the accept edits chip in the shot below. On a session Caprock started, the chip is a menu:

⤢

⤢

• Manual, accept edits, plan, auto, and bypass when the process can reach it, switch in place: Caprock presses Shift+Tab for you and checks the session's own footer to confirm the switch.
• Bypass in a process started without it, and don't ask, are Restart in …: after a confirm, and only while Claude is at its prompt, the same conversation resumes in a new process in the same tab.
• The first bypass on a computer asks for Claude Code's consent once, in Caprock's own dialog, so nobody presses Enter on No, exit. Once given, new sessions start with --allow-dangerously-skip-permissions, so bypass is a switch away without being their mode.
• A session started in another terminal shows its mode read-only; Caprock never types into a process it did not start.

New sessions start in Accept edits · asks first on a new install; the mode you pick in the New agent sheet is kept for the next one.

Skipping prompts also means nobody read the commands as they ran. With hooks on, Caprock receives every tool call from every Claude Code session on the machine, in any mode, and keeps it. caprock export writes them out, one row per call. A day on my machine, read 4 October 2026:

$ caprock export --since 24h --agent claude > day.tsv
$ grep tool.pre day.tsv | cut -f7 | sort | uniq -c | sort -rn | head -5
4593 Bash
 505 Write
 382 WebFetch
 258 Read
 213 mcp__claude-in-chrome__computer

A session's Changes tab lists the files it changed, and a session that repeats itself gets a loop alert; a session waiting on a prompt nobody saw gets a row, and a phone alert (Claude Code stuck). Caprock watches and switches modes; it does not block tool calls — for that, use deny rules, a hook or a sandbox.