DEV Community

aicoding-guide
aicoding-guide

Posted on Originally published at aicoding-guide.com

When bypassPermissions is safe to use in Claude Code, and when it isn't

#claudecode #bypasspermissions #permissions #security

Originally published at https://aicoding-guide.com.

--dangerously-skip-permissions does remove the approval prompts, and the documentation is direct about the conditions for using it: a container, VM, or sandbox runtime where Claude Code cannot damage your host.

It is not a setting to leave on for everyday work on your development machine. Here is what it turns off, what survives it, and what to reach for instead.

Key point
What you will learn

  • What bypassPermissions disables, and what still stops it
  • How it is enabled, and why it refuses to start as root
  • The risks that isolation does not remove, and the alternatives

What it turns off, and what survives

bypassPermissions disables permission prompts and safety checks so tool calls execute immediately, including writes to protected paths that no other mode auto-approves.

Not everything goes through, though. The documentation lists actions no mode auto-approves.

Category Behavior in bypassPermissions
Tools matching a deny rule Blocked
Allow rules No effect
Tools matching an explicit ask rule Prompted
AskUserQuestion and MCP tools marked requiresUserInteraction Prompted
rm and rmdir targeting a critical path Prompted; no allow rule or PreToolUse hook approves them
Cross-session messaging safeguards Still applied
Reads outside working directories with blockReadsOutsideWorkingDirectories on Prompted (v2.1.257+)

In a non-interactive -p run, those calls that would otherwise prompt are denied instead.

It is not a defense against prompt injection
The documentation states plainly that bypassPermissions offers no protection against prompt injection or unintended actions. If your goal is simply fewer prompts, look at auto mode, where a classifier reviews actions before they run.

How it is enabled

You cannot enter this mode from a session you started without it. It has to be decided at launch.

claude --permission-mode bypassPermissions
claude --dangerously-skip-permissions
Enter fullscreen mode Exit fullscreen mode

The two are equivalent. To enable it from settings, set permissions.defaultMode to "bypassPermissions" — but only user settings, --settings, and managed settings are honored. Set it in .claude/settings.json or .claude/settings.local.json and it does not take effect; the session starts in Manual mode instead. Cloud sessions also ignore the value from settings files.

Four more constraints apply:

  1. The first interactive session with the mode enabled shows a warning dialog asking you to accept responsibility. Your acceptance is saved to user settings, so it appears once. Declining exits Claude Code.
  2. No dialog is shown in non-interactive mode, and a background session started with --bg is refused until you have accepted the dialog in an interactive session.
  3. On Linux and macOS, running as root or under sudo is refused with --dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons. The check is skipped automatically inside a recognized sandbox.
  4. A session started with --restricted refuses the mode (v2.1.248+).

The conditions the documentation sets

  • Isolation: a container, VM, or sandbox runtime, where Claude Code cannot damage the host system
  • Non-root: the dev container configuration runs Claude Code as a non-root user. Check that remoteUser is a non-root account
  • Restricted network egress: the reference dev container ships init-firewall.sh, which limits outbound traffic to allowed destinations. Running the firewall requires the NET_ADMIN and NET_RAW capabilities
  • Trusted repositories only: use it on repositories you trust, and watch what Claude does

What a container does not prevent
The documentation states that with --dangerously-skip-permissions, a dev container does not prevent a malicious project from exfiltrating anything accessible inside the container — including credentials in ~/.claude. Don't mount ~/.ssh or cloud credential files, and prefer repository-scoped or short-lived tokens. Remember too that a bind-mounted workspace is your real files on the host.

What to use instead

If the goal is fewer prompts, the documentation pairs each goal with a setup.

Goal Start with Isolation needed
Fewer prompts while keeping safety checks Auto mode None required; a sandbox or container adds defense in depth
A strict allowlist in CI --permission-mode dontAsk with --allowedTools Whatever the CI runner provides
Fewer local prompts without the classifier Manual mode plus the Bash sandbox's auto-allow The built-in Bash sandbox
Fully unattended in a container claude -p "<prompt>" --dangerously-skip-permissions A container, VM, or sandbox runtime

To block the mode organization-wide, set permissions.disableBypassPermissionsMode to "disable". It is usually placed in managed settings, but it works from any scope — you can even set it in your own user settings to lock yourself out.

For the rule design underneath all of this, see Claude Code permissions in settings.json. For non-interactive runs, see Running Claude Code headless in CI.

Summary

  • --dangerously-skip-permissions equals --permission-mode bypassPermissions, and can only be enabled at launch
  • Deny rules, explicit ask rules, and rm on critical paths still stop it
  • Linux and macOS refuse to start it as root or under sudo; non-root execution is the expectation
  • The documented conditions are isolation, non-root, restricted egress, and trusted repositories
  • A container still does not prevent credential exfiltration, so try auto mode first if you only want fewer prompts

Top comments (0)