Claude Code Bypass Permissions: Using --dangerously-skip-permissions with Isolation

Q: What is the Claude Code bypass permissions command?

`claude --dangerously-skip-permissions`, which is equivalent to `claude --permission-mode bypassPermissions`. It skips normal permission prompts and safety checks, but explicit deny and ask rules and several documented safeguards still apply. Use it only inside an isolated environment such as a disposable container or VM.

Q: Is bypass permissions the same as auto accept mode?

No. `auto` is the official classifier-backed permission mode. `acceptEdits`, sandbox auto-allow, `dontAsk`, and `bypassPermissions` are separate mechanisms with different behavior and risk.

Q: Does claude -p skip permission prompts?

No. `claude -p` is non-interactive, but permission modes, rules, and hooks still apply. With no permission host, unresolved permission requests are denied. Use `dontAsk` with precise `--allowedTools` rules for an unattended allowlist, or `--tools` to restrict tool availability.

The direct answer

The bypass permissions command, and the one warning that matters

The command is claude --dangerously-skip-permissions. It starts a Claude Code session that skips normal permission prompts and safety checks, although documented exceptions can still prompt or block. The explicit equivalent is claude --permission-mode bypassPermissions. The --allow-dangerously-skip-permissions flag adds bypass to the Shift+Tab mode cycle without activating it.

The name is not decoration. In this mode, tool calls execute immediately within whatever operating-system, sandbox, network, filesystem, and credential boundaries the process already has. The rest of this guide covers what the flag changes, which controls remain, safer ways to reduce prompts, and how to contain a bypass run.

Last verified against the official Claude Code documentation on September 5, 2026. Behavior varies by installed version, so check the current official CLI reference together with your installed version; claude --help does not list every supported flag.

Three layers

What bypass permissions actually changes

Claude Code combines permission modes, permission rules, and sandboxed execution. Bypass changes the permission baseline, but it does not erase every control:

Permission mode: bypassPermissions disables normal permission prompts and safety checks, so tool calls execute immediately except for documented actions that no mode auto-approves.
Permission rules: explicit deny rules still block and explicit ask rules still prompt in bypass mode. Allow rules have no effect because bypass already approves everything that reaches the mode check.
Sandboxed execution: OS-level isolation applies to shell commands where supported. It is separate from permission modes, and enabling bypass neither creates nor removes a configured sandbox.

bypassPermissions provides no additional protection against prompt injection or unintended actions. Malicious instructions in repository content, or an ordinary model mistake, can lead to immediate tool calls without normal approval. Bypass is defensible only when an independent boundary contains the resulting damage. Our deeper piece on AI agent sandboxing covers that containment layer.

The exceptions

What bypass permissions does not bypass

Bypass is not a master override. Several controls still apply, and knowing them saves both surprises and support threads:

Explicit deny rules still block and explicit ask rules still prompt. Allow rules have no effect in bypassPermissions.
Tools that require user interaction by design are not auto-approved. In a claude -p run with no permission host, requests that would prompt are denied.
rm and rmdir removals targeting critical paths such as / or the home directory still go through the regular permission flow.
Cross-session messaging safeguards still apply, and with permissions.blockReadsOutsideWorkingDirectories enabled, certain reads outside working directories can also prompt in bypass mode.
If managed settings set permissions.disableBypassPermissionsMode to "disable", the mode is blocked, and lower-precedence settings or command-line flags cannot override that policy.
On Linux and macOS, Claude Code refuses to start bypass mode under root or sudo, unless it recognizes that it is already inside a sandbox.
Mid-session switching is gated. Bypass must be made available at launch through --permission-mode bypassPermissions, --dangerously-skip-permissions, --allow-dangerously-skip-permissions, or an applicable permissions.defaultMode setting.

The mode table

Claude Code permission modes compared

Bypass is one end of a spectrum, and most sessions belong somewhere else on it:

Mode	What it does	Human in the loop	Reasonable home
`default`	Runs reads without asking; prompts before most file edits, non-read-only shell commands, and network actions	Yes	Reviewing actions yourself and sensitive work
`plan`	Reads files and runs read-only shell commands; classifier-approved commands may also run where auto mode is available	Yes	Exploring a codebase before changing it
`acceptEdits`	Auto-approves file edits and common filesystem commands such as mkdir, touch, mv, and cp; other shell and network actions can still require approval	Partial	Edit-heavy work you are reviewing
`auto`	Uses a classifier and background safety checks to approve or deny actions	Not for most actions	Long tasks with fewer interruptions
`dontAsk`	Runs pre-approved tools and built-in read-only commands; actions that would otherwise prompt are denied	No	Locked-down CI and scripts
`bypassPermissions`	Runs everything except documented actions that no mode auto-approves; deny rules block and ask rules prompt	Only for documented exceptions	Isolated containers and VMs only

Current Claude Code modes are default, acceptEdits, plan, auto, dontAsk, and bypassPermissions. Use the official CLI reference for the complete current list, because claude --help does not list every flag.

One vocabulary trap: auto accept is not one feature, and auto is now an official classifier-backed permission mode. Do not use auto accept as a synonym for auto, acceptEdits, sandbox auto-allow, or bypassPermissions; they are separate mechanisms with different approval and isolation behavior.

Before you bypass

Safer ways to reduce permission prompts

Most permission fatigue has a narrower fix than removing review entirely. In order of preference:

Sandbox auto-allow: when a shell command can run inside the sandbox, Claude Code can approve it without prompting. Commands that cannot be sandboxed fall back to the regular permission flow, and explicit deny rules, content-scoped ask rules, and critical-path deletion checks still apply.
acceptEdits: use it when edit approvals are the main friction. It also auto-approves common filesystem commands, while most other non-read-only commands still follow the regular permission flow.
Precise allow rules: add only commands you already trust, such as your test runner and formatter, to permissions.allow. These rules pre-approve matching actions but do not remove other tools.
auto: the official classifier-backed mode, when you need substantially fewer prompts without disabling background safety checks.
dontAsk with --allowedTools: for unattended runs where unmatched actions should be denied rather than prompted. Note that --allowedTools pre-approves tools; use --tools when you need to restrict which tools are available at all.
PreToolUse hooks: encode your own policy in code you control that inspects and blocks unwanted tool calls. Treat repository-supplied hooks as executable code.
bypassPermissions, last, and only inside isolation designed to survive unintended actions.

Containment first

Safe setup for containers, VMs, and CI

If bypass is justified anywhere, it is inside a boundary designed for the failure case. A reasonable checklist:

Run as a non-root user inside a disposable container or VM, one run per environment.
Mount only the repository. Never your home directory, never credential stores.
No Docker socket, no host network shares, no device passthrough.
Inject no production credentials. If a token is unavoidable, make it scoped and short-lived.
Disable outbound network, or restrict it to an explicit allowlist of hosts.
Work on a temporary branch or worktree, and review the diff before anything merges.
For claude -p runs, set --max-turns and --max-budget-usd, and enforce a separate wall-clock timeout in CI.

With normal prompts gone, containment becomes the primary hard boundary. Remaining deny and ask rules and hooks provide defense in depth, but they do not replace a disposable, least-privilege environment. The same logic scales up in how to run multiple coding agents, where nobody is watching any single terminal.

Headless is separate

Headless mode with claude -p is a different decision

claude -p runs non-interactively and prints the result. It does not imply bypass: permission modes, rules, and hooks still decide tool calls. In a -p run with no permission host, any request that still requires a prompt is denied unless a PermissionRequest hook resolves it, and the run continues.

For CI, choose an explicit mode. Use dontAsk with --allowedTools when unmatched actions should be denied, and --tools when the available tool surface itself must be restricted. Add --max-turns, --max-budget-usd, and an external timeout. In unfamiliar repositories, prefer --setting-sources user to exclude project settings and .mcp.json, or use --bare to skip project hooks, skills, commands, agents, plugins, and MCP servers. A normal -p run shows no workspace trust dialog and can run repository-supplied hooks and connect .mcp.json servers.

Not working?

Why Claude Code still asks for permission

If you passed the flag and still see prompts or blocks, work down this list in order:

Confirm the status bar actually shows bypass permissions. If bypass was not made available at launch, restart with an enabling flag or applicable setting.
Check whether permissions.disableBypassPermissionsMode blocks the mode. A managed setting cannot be overridden from the command line.
On Linux and macOS, root or sudo prevents bypass mode from starting, unless Claude Code recognizes that it is already inside a sandbox.
An explicit ask rule can still prompt, and an explicit deny rule can still block.
Critical-path rm or rmdir operations, tools requiring user interaction, and cross-session messaging safeguards are not auto-approved.
With permissions.blockReadsOutsideWorkingDirectories enabled, certain reads outside the working directories can prompt even in bypass mode.
In claude -p with no permission host, calls that still require a prompt are denied instead.
An IDE integration or wrapper may expose a different set of modes or apply additional policy.

If observed behavior contradicts documentation, compare claude --version against the docs before filing anything; permission behavior is one of the faster-moving parts of the tool.

Choose deliberately

The four-question decision checklist

Before any bypass run, answer four questions honestly:

Do you trust the code and content the agent will read? Untrusted input can steer an agent that no longer stops to ask.
Is there an isolation boundary that survives a bad command: container, VM, or OS sandbox?
Is everything the run can reach expendable or scoped? Credentials and production access disqualify bypass.
Is the damage recoverable: temporary branch, disposable environment, backups?

These checks are minimum conditions, not a safety guarantee. Use bypass only when isolation prevents host damage and reachable credentials, data, and network targets have been removed or tightly bounded. Otherwise use auto, dontAsk, sandbox auto-allow, or precise permission rules.

One layer up

The same tradeoff, solved at the infrastructure layer

HarnessRouter is the world's first unified interface for agent harnesses. A unified interface means one API contract for running complete agent harnesses: starting tasks, streaming progress, continuing sessions, and collecting files and results work the same way across every harness on the platform.

Runs execute server-side, each inside its own isolated per-run sandbox, so full-speed execution and containment stop being a local flag to get right and become a property of the platform. One honest limit: a sandbox still reaches whatever you explicitly grant it, including mounted data, injected credentials, and permitted network targets. Isolation bounds the blast radius; it does not remove the need to grant carefully.

FAQ

Claude Code bypass permissions FAQ

What is the Claude Code bypass permissions command?

claude --dangerously-skip-permissions, which is equivalent to claude --permission-mode bypassPermissions. It skips normal permission prompts and safety checks, but explicit deny and ask rules and several documented safeguards still apply. Use it only inside an isolated environment such as a disposable container or VM.

Is bypass permissions the same as auto accept mode?

No. auto is the official classifier-backed permission mode. acceptEdits, sandbox auto-allow, dontAsk, and bypassPermissions are separate mechanisms with different behavior and risk.

Can I enable bypass permissions in the middle of a session?

Only if bypass was made available when the session started, through --dangerously-skip-permissions, --permission-mode bypassPermissions, --allow-dangerously-skip-permissions, or an applicable permissions.defaultMode setting. Otherwise restart with an enabling option.

Does claude -p skip permission prompts?

No. claude -p is non-interactive, but permission modes, rules, and hooks still apply. With no permission host, unresolved permission requests are denied. Use dontAsk with precise --allowedTools rules for an unattended allowlist, or --tools to restrict tool availability.

Why does --dangerously-skip-permissions still ask or block?

First confirm that bypass actually started. Explicit ask and deny rules, critical-path deletion checks, user-interaction tools, cross-session safeguards, and certain blocked reads can still prompt or block. Managed policy, missing startup enablement, or root and sudo restrictions may prevent bypass from starting at all.

Run agents with containment built in

Start a task through one API and let every run execute server-side in its own isolated sandbox, with sessions, streaming, and artifacts handled for you.

Run your first agent free