How do I run Claude Code with bypassPermissions?

claude --permission-mode bypassPermissions

Starts a session with permission prompts bypassed.

Answer

Run claude --permission-mode bypassPermissions to start a session where Claude acts without asking for confirmation. Use it only in an isolated environment such as a disposable container or virtual machine. Claude Code refuses to start this mode as root or under sudo on Linux and macOS, and a few safety checks still prompt even here.

What it does

Claude Code normally asks before it edits a file or runs a command. In bypassPermissions mode it stops asking and acts directly.

claude --permission-mode bypassPermissions

The mode also lifts the protected-path rule, which normally blocks writes to .git and .claude.

Six things still interrupt Claude even in this mode:

explicit ask rules in your permission settings
MCP tools marked as requiring user interaction
connector tools your organisation set to ask
a circuit breaker for rm and rmdir aimed at a critical path: the filesystem root, any top-level directory, your home directory, or your working directory and its parents, including attempts hidden inside command substitution
two cross-session messaging safeguards: the approval prompt for messages to your sessions on other machines, and holding an inbound message from another session for your approval unless the sender is also bypassing prompts
reads outside the working directories, once permissions.blockReadsOutsideWorkingDirectories is on (v2.1.257 and later)

Treat those as a last line of defence, not as a safety net. Everything else runs unattended, and permissions.allow rules have nothing left to allow: they have no effect in this mode.

When to use it

The mode fits work where a review step per action would stall the task and the environment is disposable:

a throwaway container or virtual machine you can rebuild
a long batch of mechanical edits you have already scoped
a sandbox where the worst outcome is rebuilding the sandbox

Interactive sessions show a warning dialog the first time you start this mode and require you to accept it. Decline and Claude Code exits; accept and it records skipDangerousModePermissionPrompt: true in your user settings, so the dialog does not return. Non-interactive runs with -p skip that dialog, which is exactly why the environment has to be disposable, and a background session started with --bg is refused until you have accepted it once interactively.

When not to use it

Do not use it on a machine where losing files would cost you anything: your main working checkout, a shared server, or anything with production credentials in reach.

If what you want is fewer prompts rather than no prompts, three narrower options exist:

acceptEdits auto-approves file edits and a small set of filesystem commands, and keeps prompting for everything else
permissions.allow rules pre-approve exactly the commands you name
auto mode removes the routine prompts but keeps a reviewer that can say no; the documentation itself points to it as the alternative to this mode, and the two are compared here

All three keep a boundary. bypassPermissions does not.

The mode is also unavailable in cloud sessions on Claude Code for the web: the setting is ignored there rather than applied. An administrator can remove it everywhere with permissions.disableBypassPermissionsMode in managed settings, which also rejects the flag, and a session started with --restricted (v2.1.248 and later) refuses it.

Example

Start a session with prompts bypassed:

claude --permission-mode bypassPermissions

The shorter alias does the same thing:

claude --dangerously-skip-permissions

Running either as root fails by design on Linux and macOS:

--dangerously-skip-permissions cannot be used with root/sudo privileges for security reasons

The check is skipped inside a recognised sandbox. The supported way to get one is Claude Code's own dev container configuration, which runs as a non-root user. Build on that rather than trying to convince the check you are sandboxed.

Security considerations

The risk is not that Claude behaves maliciously. It is that an instruction with a mistake in it now executes without a human reading it first, and destructive steps are indistinguishable from useful ones until they have run.

That risk compounds when the session can reach anything you would not want rebuilt from scratch: credentials in environment variables, an SSH agent, a mounted network drive, a cloud CLI already authenticated.

A workable setup:

run inside a container with only the project directory mounted
keep credentials out of the container environment
commit your work before starting, so the diff is recoverable

The root refusal exists because running as root removes the last filesystem boundary. Get a real sandbox instead of looking for a way past the check.

Common mistakes

Using it to silence a repeated prompt. If one command keeps asking, add it to permissions.allow instead. That fixes the specific prompt without removing every other one.

Assuming the guardrails are broad. The circuit breaker covers removals aimed at /, top-level directories, your home directory and your working directory itself. It will not stop rm -rf on a subdirectory inside your project, which is the deletion most likely to actually happen.

Setting it as a persistent default. Putting bypassPermissions in permissions.defaultMode of your user settings means every future session starts unguarded, including ones you open months later for unrelated work. From v2.1.257 a project or local file cannot do this at all: the value is ignored there and the session starts in Manual.

Expecting it to work in cloud sessions. On Claude Code for the web the setting is ignored, so a workflow that depends on it will behave differently there than on your machine.