When bypassPermissions is safe to use in Claude Code, and when it isn't
What --dangerously-skip-permissions actually turns off, what still stops it, the isolation conditions the docs require, and the alternatives worth trying before you reach for it.
Contents
--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
bypassPermissionsdisables, 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-permissionsThe 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:
- 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.
- No dialog is shown in non-interactive mode, and a background session started with
--bgis refused until you have accepted the dialog in an interactive session. - On Linux and macOS, running as root or under
sudois refused with--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons. The check is skipped automatically inside a recognized sandbox. - A session started with
--restrictedrefuses 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
remoteUseris 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 theNET_ADMINandNET_RAWcapabilities - 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-permissionsequals--permission-mode bypassPermissions, and can only be enabled at launch- Deny rules, explicit ask rules, and
rmon 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
FAQ
- Are --dangerously-skip-permissions and bypassPermissions different things?
- No. The documentation states that --dangerously-skip-permissions is equivalent to --permission-mode bypassPermissions.
- Can I switch into bypassPermissions mid-session?
- No. You cannot enter it from a session started without it enabled. Enable it at launch with a flag, or with defaultMode in user, --settings or managed settings.
- Do deny rules still apply in bypassPermissions?
- Yes. Deny rules block in every mode, including bypassPermissions. Allow rules, on the other hand, have no effect there.
Questions & answers
Q. With the sandbox enabled on Linux, every Bash tool call fails with Exit code 126 and no output at all. What causes this?
This is reported when your login shell is zsh and sandbox.enabled is true. The workaround is one line:
SHELL=/bin/bash claudeThe reported symptom is that "every sandboxed Bash tool call fails with Exit code 126 and zero bytes of stdout/stderr, in ~1.3s — including shell builtins (true, type echo)". Shell builtins such as true failing is the tell: it means nothing about your particular command or configuration is at fault.
According to the reporter, the script that runs inside the sandbox uses the bash-only form exec 3<&- || exit 126. Closing an already-closed file descriptor is tolerated by bash but fails under zsh, so the script exits 126 before it ever evaluates your command. That is the reporter's analysis, not documented behaviour.
| Aspect | Detail |
|---|---|
| Conditions | Linux, zsh as the login shell, sandbox.enabled: true |
| Symptom | Every Bash tool call exits 126 in about 1.3s with no output |
| Working versions | The reporter verified 2.1.270, 2.1.286, 2.1.289 and 2.1.291 |
| Failing versions | The reporter reproduced it on 2.1.302 and 2.1.309 |
| Workaround | Launch with SHELL=/bin/bash claude |
Check the shell before you suspect your settings
The reporter says it reproduces in interactive mode and under -p, in fresh sessions, and with permissions.deny emptied — so trimming permission rules will not help. When you see exit 126 with zero output, check echo $SHELL first.
A similar report exists for Seatbelt on macOS (#77466). If you turn the sandbox off to keep working, remember that it changes what gets auto-approved; see bypassPermissions in Claude Code and how dangerous operations are handled.
Primary sources
This article was drafted by AI from official documentation and reviewed by the site operator before publishing. Found a mistake? Let us know via the contact page.