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.
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.