What Does dangerously-skip-permissions Do in Claude Code?

What Does dangerously-skip-permissions Do in Claude Code?

The first hour of using Claude Code is pleasant. The second is a permission prompt every ninety seconds. By the third you are approving things without reading them, which is worse than having no prompts at all.

So somebody tells you about --dangerously-skip-permissions, and the name does most of the arguing.

It is not a nickname or a community hack — it is an official, documented flag with a deliberately unpleasant spelling, chosen to make you think once before typing it.

The interesting part is not that it turns prompts off. It is what it still refuses to do, why it will not start at all in some environments, and the gap between what people assume it protects them from and what it actually does.

What Does the Flag Actually Do?

--dangerously-skip-permissions puts the session into the permission mode named bypassPermissions. In the interface it appears as "Bypass permissions".

In that mode the documentation describes permission prompts and safety checks as disabled, with tool calls executing immediately, including writes to protected paths.

Reads, edits, shell commands, network access — all of it runs without asking, and without a classifier reviewing it first.

That is the whole feature. There is no partial version, no reduced set, no review step. Everything that would normally stop and ask you simply happens.

Automating your work is only a win if the measurement behind it is sound. Get a free SEO audit and see what your tracking is actually capturing.

What It Skips, and What It Still Will Not Do

This is the section worth reading carefully, because the mode is less absolute than its name suggests — and the places where it holds the line are exactly the places people assume it does not.

Deny rules still block

The documentation is explicit: deny rules block in every mode, including bypassPermissions. If you have written a deny rule for a path or a command, bypass mode does not override it.

The inverse is also true and less obvious: allow rules have no effect in this mode. There is nothing left for them to approve, so a carefully built allow list simply stops being consulted.

Some removals are refused outright

Recognised rm and rmdir removals on critical paths are blocked, as are commands flagged internally as a dangerous removal that cannot be ruled out. No allow rule and no approving hook gets past that check. On PowerShell, Remove-Item is denied.

This is the one guardrail that survives everything, and it exists because the failure it prevents is unrecoverable.

Prompts that need a human still appear

A handful of interactions cannot be auto-approved because their entire purpose is to ask a person something:

• Tools matched by an explicit ask rule.
• Connector tools an organisation has set to ask.
• The question tool Claude uses to put a choice to you, and MCP tools marked as requiring user interaction.
• Cross-session messaging safeguards, including the prompt that isolates peer machines. Inbound messages from your other sessions are held for approval unless the sending session also bypasses prompts.
• Reading another organisation's public artifact, which needs your approval and so cannot happen in this mode at all.

There is also a settings option that blocks reads outside the working directories, and it keeps working in bypass mode.

In current documentation it is version-gated, which is a useful signal in itself: the mode is still being actively developed rather than quietly deprecated.

One behaviour that surprises people

In interactive terminal sessions where bypass is available, plan mode's edit blocks are not enforced. Claude is still instructed to plan, but edits and shell commands run without prompting.

Plan mode keeps its blocks under the non-interactive -p flag, in the Agent SDK, and in the VS Code chat panel — but in a plain terminal with bypass enabled, "plan mode" is no longer a safety boundary.

Unattended automation deserves trustworthy baseline data. Get a free SEO audit and start from numbers you can rely on.

How Do You Turn It On, Step by Step

There are more routes than you would expect, and one of them does not work in the place most people try it first.

Step 1: use the flag for a one-off run. claude --permission-mode bypassPermissions is the canonical spelling, and the documentation states --dangerously-skip-permissions is equivalent. Use whichever you prefer; they do the same thing.

Step 2: accept the warning the first time. The first interactive start in this mode shows a dialog asking you to accept responsibility. Accepting writes "skipDangerousModePermissionPrompt": true into your user settings file at ~/.claude/settings.json. Declining exits. Non-interactive runs show no dialog at all.

Step 3: set it as a default, in the right file. The settings key is "permissions": { "defaultMode": "bypassPermissions" }, and the scope matters enormously. It works in user settings, in a file passed with --settings, and in managed settings. It does not take effect in .claude/settings.json or .claude/settings.local.json — a session configured there starts in Manual instead, with no error to tell you why.

Step 4: know how the Shift+Tab cycle behaves. Bypass appears in the cycle only if the session was started with it enabled — via the flag, via --allow-dangerously-skip-permissions, or via defaultMode from one of the scopes above. That middle flag is the useful one: it adds bypass to the cycle without activating it, so you can switch into it deliberately mid-session. You cannot enter the mode from a session that started without it available.

Step 5: flip the toggle in the GUI surfaces. In VS Code, the "Allow dangerously skip permissions" toggle is required; without it, a bypassPermissions value starts the conversation in Manual. In the desktop app the equivalent is an "Allow bypass permissions mode" toggle, available on the individual paid plans, with Team and Enterprise following organisation policy. Cloud sessions ignore the setting from settings files entirely.

Step 6: expect background runs to refuse until you have accepted once. Launching a background session in bypass mode is refused until the acceptance has happened in an interactive session, and the acceptance key is ignored if it only exists in the local project settings file. The error names the file it wants.

Why It Refuses to Run as Root

On Linux and macOS, Claude Code will not start in this mode as root or under sudo. It exits with a message saying the flag cannot be used with root or sudo privileges for security reasons.

This catches people inside Docker containers, where running as root is the lazy default. The check is skipped inside a recognised sandbox, and the documentation points at the dev container as the supported route, because it runs as a non-root user.

The logic is worth understanding rather than routing around. Bypass removes the prompts that would stop a bad command; root removes the file permissions that would stop it.

Together there is nothing left between a mistake and your system, which is why this is the one place the tool overrides your stated preference.

Running unattended processes against your site data? Get a free SEO audit before you automate on top of numbers you have not verified.

When Is It Actually the Right Mode?

There is a legitimate case, and it is narrower than the flag's popularity suggests.

Disposable, isolated environments. The documentation is blunt: only use this mode in isolated environments like containers, VMs, or dev containers without internet access. A throwaway container with a copy of a repository and no credentials in it is the intended home for this flag.

Long unattended runs where prompts would simply stall. A migration across hundreds of files, a large refactor, a batch job running overnight. A prompt nobody answers is a job that did not finish. For these, the documentation requires a container, VM, or the sandbox runtime rather than your working machine.

Work with no blast radius. A scratch directory, generated code, a sandboxed experiment. If the worst case is deleting something you can regenerate in a minute, the risk calculation genuinely changes.

When you have deny rules doing the real work. Because deny rules survive bypass mode, a well-written deny list plus bypass is a materially safer configuration than bypass alone. This is the most underused pattern in the whole feature.

What is not on that list: your main development machine, a repository with production credentials in it, or any session that will browse the web and act on what it reads.

What Are the Limitations and Risks Worth Knowing?

It offers no protection against prompt injection. The documentation states this directly, and it is the risk people underestimate most. In Manual or Auto mode, content fetched from a web page that tries to steer Claude into a destructive action meets either you or a classifier. In bypass mode it meets nothing. Any session reading untrusted input — a web page, an issue tracker, a pull request from a stranger — is a session where this mode is a bad idea.

There is no review, not even a fast one. Auto mode runs a classifier over actions before they execute. Bypass reviews nothing at all. These are not points on the same scale; they are different designs.

Your allow list stops mattering. If you have invested time in a precise allow configuration, bypass mode discards all of it while keeping only the denials. The configuration you tuned is not what is protecting you.

The settings scope trap is real. A defaultMode of bypassPermissions placed in project settings is silently ignored. You will conclude the flag does not work when in fact the file was wrong.

Administrators can switch it off. Managed settings support "permissions": { "disableBypassPermissionsMode": "disable" }, which prevents the mode being used at all. On a work machine, that is a policy question, not a troubleshooting one. A session-starting restricted flag also refuses bypass in the sessions it starts.

Version-specific details move. Flags, version gates and toggle names in this area have changed more than once. Treat any specific version number — including the ones in this article — as true at the time of writing and worth confirming against the current documentation before you rely on it.

How Does It Compare to Auto Mode and Edit Automatically?

Claude Code offers several permission modes, and bypass sits at one end of the range rather than being the only alternative to prompts.

Manual, the default, runs reads only. Edits, shell commands and network access all ask first. Correct for unfamiliar code, exhausting for long tasks.

Edit automatically (acceptEdits) approves reads, file edits, and a short list of filesystem commands inside the working directory or additional directories you have named. Protected-path writes still prompt, and anything outside that list still prompts. This is the mode most people actually want when they reach for bypass: it removes the prompt fatigue from editing without removing the review from everything else.

Auto mode approves everything, but a separate classifier model reviews each action before it runs, blocking privilege escalations, actions driven by hostile content, and the blocked-by-default list. Ask rules still prompt. It is the closest thing to bypass that retains a safety argument, and for most unattended work it is the better default.

Plan mode runs reads, plus shell commands the classifier approves where auto is available, and blocks edits until you approve a plan — with the caveat above that bypass availability undermines those blocks in an interactive terminal.

Bypass permissions approves everything and reviews nothing.

Read as a sequence, the design intent is clear. Bypass is not the convenient end of a spectrum of convenience; it is the exit from the spectrum.

If what you want is fewer prompts, the mode you want is almost certainly acceptEdits or auto.

Most teams automate the work and never revisit the measurement. Get a free SEO audit and find out what your site is really doing.

Final Thoughts

The flag is named the way it is named on purpose, and the honest summary is that the name is accurate. It skips the prompts and the safety checks.

It keeps your deny rules, refuses a few catastrophic removals, and will not start as root — and that is the entire extent of what it protects you from.

The question to ask before using it is not "how much do I trust Claude" but "what is in reach of this session". A container with a disposable copy of a repository: fine, and this is what the mode is for.

Your laptop, with your credentials, during a session that will read things from the internet: the prompts you find annoying are the only thing standing between those two facts.

If the actual problem is prompt fatigue rather than a need for true unattended execution, our guide to auto mode in Claude Code covers the mode that solves it while keeping a review step in place.