At a glance
- What it is:
--dangerously-skip-permissionsstarts Claude Code inbypassPermissionsmode. The docs call it equivalent to--permission-mode bypassPermissions.- What it skips: Routine permission prompts and the safety checks on protected paths such as
.gitand.claude.- What still applies: Deny rules, explicit ask rules,
rmandrmdiron critical paths, and a short list of other checks.- Where it belongs: Inside a container, VM, or sandbox runtime. Anthropic’s isolation guidance says the boundary is then the only thing limiting what Claude can do.
- Who can restrict it: Admins can prevent its use by configuring
permissions.disableBypassPermissionsModewith the value"disable".- The alternative: Auto mode retains classifier-based checks when processing requests.
The name was chosen to make you hesitate. When the --dangerously-skip-permissions flag appears in a tutorial, a CI script, or a teammate’s shell alias, it usually shows up with a shrug and a promise that everything is fine. Sometimes it is. People often overlook what the mode actually removes or bypasses.
This guide covers Claude Code dangerously-skip-permissions from the ground up: what the flag does, what it leaves in place, where it is available, how to enable and block it, what the risks look like in practice, and what the alternatives are now that auto mode exists. It is written for developers, security-minded engineers, and team leads who want an accurate picture before they type the flag.
A note on method. Everything below comes from Anthropic’s published documentation, its engineering write-up on auto mode, public issue trackers, and clearly labeled third-party coverage. Nothing here describes personal experience with the tool. Claude Code ships often, so the version numbers cited are signposts. Confirm current behavior against the live docs before you rely on a detail.
Table of Contents
What Claude Code –dangerously-skip-permissions Actually Does
By default, Claude Code pauses before most actions that edit files, run shell commands, or reach the network. A permission mode decides how often that pause happens. In bypassPermissions mode, the documentation explains that Claude Code skips permission requests and safety checks, allowing tool calls to run without delay, even when they modify protected paths.
The flag is a shortcut into that mode. The docs state that --dangerously-skip-permissions is equivalent to starting with --permission-mode bypassPermissions. Both forms appear in the official “common setups” table, which lists the flag as the way to “run fully unattended inside a container.”
A note on naming. Some community guides describe the flag as deprecated or as an “older” form. The official permission modes page does not say that. It lists both spellings as equivalent, so treat the deprecation claim as unconfirmed.
The Informal Names
Developers often call this “YOLO mode.” That label is community slang, not Anthropic’s term. The official name is bypassPermissions, and the Desktop app’s equivalent is labeled “Bypass permissions.” Searching for either phrase leads to the same feature.
The Three Ways to Reach the Mode
The docs describe several entry points:
| Method | Effect |
|---|---|
--permission-mode bypassPermissions | Starts the session in bypass mode |
--dangerously-skip-permissions | Same result |
--allow-dangerously-skip-permissions | Adds bypass to the Shift+Tab cycle without activating it |
permissions.defaultMode: "bypassPermissions" | Starts in bypass mode when set in user, --settings, or managed settings |
The third row matters for planning. The --allow- variant lets you launch in a safer mode and switch up later. The docs also say you cannot enter bypass mode from a session that was not started with it enabled, so the decision has to be made at launch.
What the Mode Skips and What Still Applies
The most useful distinction in the documentation is between what bypass mode removes and what no mode can remove. People often assume the flag turns off everything. It does not.
What Is Skipped
Routine permission prompts are gone. Allow rules have no effect in this mode, because nothing needs approving. Writes to protected paths, which every other mode either prompts for, routes to the classifier, or denies, are allowed. The protected list includes .git, .vscode, .idea, .husky, .devcontainer, and .claude, plus files such as .bashrc, .zshrc, .gitconfig, .npmrc, .mcp.json, and .claude.json.
That last group deserves a second look. Shell startup files, git configuration, and Claude’s own settings are exactly where an unwanted change would persist beyond a session. In other modes they are guarded on purpose, to prevent accidental corruption of repository state and Claude’s configuration. In bypass mode that guard is off.
In interactive terminal sessions where bypass permissions are available, plan mode’s blocks are not enforced either. Claude is still told to plan without editing, but an edit or shell command it attempts during planning runs without a prompt. Plan mode keeps its blocks in non-interactive -p runs, Agent SDK sessions, and the VS Code chat panel.
For a closer look at the safer planning workflow and its limitations, read our guide to Claude Code Plan Mode
What Still Applies
The docs publish a list of “actions no mode auto-approves.” Here is how they compare against normal behavior:
| Check | Behavior in bypass mode |
|---|---|
| Deny rules | Still block |
| Explicit ask rules | Still prompt |
rm and rmdir on critical paths | Still prompt; no allow rule or hook approves them |
Tools requiring user interaction (such as AskUserQuestion) | Still require a person |
Connector tools your organization set to ask | Still prompt |
| Cross-session messaging safeguards | Still apply |
Reads outside working directories, when blockReadsOutsideWorkingDirectories is on | Still prompt (v2.1.257 or later) |
Remove-Item on system paths in PowerShell | Denied |
| Another organization’s public artifact | Needs approval, so Claude cannot read it |
The practical lesson is that deny rules are your most important lever. Hooks can provide another layer of workflow enforcement, although they should not be treated as a substitute for proper isolation; see our guide to Claude Code hooks. A deny rule such as Bash(rm *) applies in every mode, including bypass. If you are going to skip prompts, writing a few deny rules first is cheap insurance, though the docs note rules match commands as written, so they are not a complete defense.
Critical-Path Removals
The documentation describes a “circuit breaker” for deletions. Claude Code does not allow permission rules or PreToolUse hooks to authorize rm or rmdir commands that target critical filesystem locations. These include the root directory, system directories such as /usr and /etc, your home directory, your current working directory, and any parent directories above it. The check also catches risky shell patterns, such as rm -rf "$DIR"/*, where an empty variable would turn the command into a removal from the root.
In bypass mode, a terminal prompt starts a two-minute timer. If the time runs out, the command is blocked, and Claude is instructed to try another approach. After three unanswered prompts in a session, further critical-path removals are denied immediately. The docs tie this handling to Claude Code v2.1.281 or later, and describe it as a guard against model error. It is a narrow safety net. It does not protect a project directory’s contents that fall outside the critical-path definition.
Where the Mode Is Available
Availability differs by surface, and several surfaces deliberately restrict it.
| Surface | Bypass permissions |
|---|---|
| Terminal CLI | Available through the flag or settings |
| VS Code extension | Requires the “Allow dangerously skip permissions” toggle; claudeCode.initialPermissionMode can pin it |
| JetBrains plugin | Same as the CLI, since it runs in the IDE terminal |
| Desktop app | Pro and Max: a settings toggle. Team and Enterprise: controlled by organization policy |
| Cloud sessions on the web | Not available |
| Remote Control sessions | Cannot be selected from the app |
Non-interactive claude -p | Available; no confirmation dialog appears |
| Background sessions | Refused unless the warning was accepted in user or managed settings |
Two details are worth underlining. Cloud sessions ignore defaultMode: "bypassPermissions" from settings files, so a repository’s checked-in configuration cannot put a cloud session into bypass mode. On Linux and macOS, Claude Code will not launch in bypass mode when run as root or through sudo. It displays a security error stating that the flag cannot be used with root or sudo privileges. This restriction is automatically skipped in a recognized sandbox, while the reference development container runs Claude Code under a non-root account.
Project Settings Cannot Turn It On
A repository cannot grant itself bypass mode. If permissions.defaultMode is set to "bypassPermissions" in a project’s .claude/settings.json or .claude/settings.local.json, it does not take effect, and the session starts in Manual mode. The same holds for auto. This is a sensible defense against a cloned repository that would otherwise start your session with no prompts. Put the value in ~/.claude/settings.json, a --settings file, or managed settings if you truly want it as a default.
A GitHub bug report adds a practical warning from the community side: invented keys such as permission-mode or dangerouslySkipPermissions under permissions are silently ignored. The documented key is permissions.defaultMode.
The First-Run Warning
The first time you enter this mode in an interactive session, Claude Code presents a warning dialog requiring you to accept responsibility for actions performed without permission checks. Accepting writes skipDangerousModePermissionPrompt: true to ~/.claude/settings.json, so later sessions skip the dialog. Declining exits Claude Code. In non-interactive mode no dialog appears at all.
Background sessions add a wrinkle. With no recorded acceptance, claude --bg --permission-mode bypassPermissions is refused. If the acceptance exists only in .claude/settings.local.json, the session starts with the bypass request ignored and says so. Putting "skipDangerousModePermissionPrompt": true in ~/.claude/settings.json is the documented fix. Note that this setting only suppresses the dialog. It does not itself enable bypass mode.
Why the Flag Is Called Dangerous
The documentation gives a blunt warning: bypass mode offers no protection against prompt injection or unintended actions. It is worth separating the risks so you can judge which ones matter for your setup.
Overeager Agents and Honest Mistakes
Anthropic’s engineering article on auto mode explains the threat model with unusual candor. It lists four reasons an agent might take a dangerous action: overeager behavior, honest mistakes, prompt injection, and a misaligned model. The article says the team does not currently see the fourth in practice. The first two are the everyday ones. An overeager agent understands your goal and tries to help, but takes initiative beyond what you would approve, for instance by using a credential it happened to find.
The article shares examples from Anthropic’s internal incident log, including deleting remote git branches after a misread instruction, uploading an engineer’s GitHub auth token to an internal compute cluster, and attempting migrations against a production database. These are described as results of the model being overeager, and they are the type of action that a permission prompt would have given you a chance to stop.
Prompt Injection
Instructions planted in a file, web page, or tool output can hijack an agent and redirect it from your task. With prompts on, a person might notice a strange command. With prompts off, nothing sits between the injected instruction and execution, except whatever isolation you set up. The docs make this point in their isolation guidance: because the flag removes per-action review other than explicit ask rules, an isolation boundary is the only thing limiting what Claude can do.
The Blast Radius Question
The risk is not abstract. Claude Code can read your environment variables, your SSH keys if they are reachable, your cloud credentials, and your files. The danger depends on what is within reach of the process. That framing explains why Anthropic’s advice centers on where you run the flag, not only whether you do.
Isolation: The Part Anthropic Treats as Mandatory
If one idea from the documentation deserves to stick, it is this: permission modes decide whether a tool call runs and whether you are asked first, while isolation decides what a call can reach once it runs. Bypass mode removes the first control. Isolation is the replacement.
The isolation guidelines recommend running sessions launched with --dangerously-skip-permissions inside a container, virtual machine, or sandbox runtime. This ensures that file tools, MCP servers, and hooks are also covered by the same security boundary. This detail is important because a sandbox that restricts only shell commands leaves file tools and MCP servers unprotected by that boundary.
Because connected MCP tools can introduce additional access and prompt-injection risks, review how Claude Code MCP servers work and why their security matters.
Your Isolation Options Compared
Based on the docs’ own comparison, here is how the main options stack up:
| Option | What it covers | Documented fit |
|---|---|---|
Bash sandbox (/sandbox) | Shell commands only, on macOS, Linux, and WSL2 | Cutting prompts during everyday work on your own machine |
Sandbox runtime (npx @anthropic-ai/sandbox-runtime claude) | The whole Claude Code process, including file tools, MCP servers, and hooks | Unattended work; denies writes and network by default until you configure it |
| Dev container | A full container with its own filesystem and, in the reference setup, a firewall | Unattended work with --dangerously-skip-permissions |
| Container or VM of your own | Whatever boundary you build | Unattended work, CI |
The docs state that the built-in Bash sandbox is not enough on its own for bypass mode, because it covers commands, not the other tools.
The Reference Dev Container
Anthropic provides an example dev container in the claude-code repository that uses a default-deny iptables firewall. To use it, the guidance recommends copying the configuration into your own repository and customizing the firewall allowlist, container base image, and pinned Claude Code release. By preventing connections to unauthorized destinations, this setup can support unattended workflows that run with --dangerously-skip-permissions, according to the documentation. The container also runs Claude Code as a non-root user, which sidesteps the root and sudo refusal.
A few practical notes from community write-ups, which you should verify against the current reference files. The firewall relies on iptables, so the container needs extra Linux capabilities, such as NET_ADMIN and NET_RAW, to start it. One tutorial warns that omitting them makes the firewall script fail quietly, which would leave you with a container that looks protected and is not. A community Elixir dev container lists a further honest limit: a firewall that restricts only ports 80 and 443 does not control other protocols.
What the Internet Question Looks Like
A GitHub issue from earlier this year pointed out that two pages of Anthropic’s documentation gave slightly different advice, one saying to use the flag only in a sandbox without internet access, the other allowing a container with strict egress filtering. The current isolation guidance leans toward the second framing: block unapproved egress, allow what the task needs. The underlying concern stays the same. Even inside a container, unrestricted network access creates a risk that the agent could send accessible information outside the environment, including credentials mounted into it. Treat what you mount into the container as the real exposure.
Auto Mode: The Middle Path
Anthropic built auto mode partly to answer this exact problem. Its engineering article lays out the tradeoff plainly. Sandboxing is safe but high-maintenance. Bypassing permissions is zero-maintenance but offers no protection. Manual prompts provide a compromise between strict controls and unrestricted access, although users accept 93% of these requests in practice. Later coverage of the decision to make auto mode the default cites a figure of 97%, so the exact number depends on which Anthropic statement you read. The shared point is approval fatigue.
Auto mode replaces the human approver with a classifier. In Anthropic’s description, a server-side probe scans tool results for injection attempts, and a transcript classifier evaluates each action before it runs. The classifier is reasoning-blind by design: it sees your messages and the agent’s tool calls, not the agent’s own explanations or tool outputs.
What the Published Numbers Say
The article reports results on three datasets. The deployed two-stage pipeline showed a 0.4% false positive rate on 10,000 real internal tool calls. On 52 curated real overeager actions, it missed 17%. On 1,000 synthetic data-exfiltration attempts, it missed 5.7%. Anthropic calls the 17% figure “the honest number,” and says whether it is acceptable depends on your comparison point. Compared with using --dangerously-skip-permissions, the documentation presents this approach as a significant improvement. Compared with carefully approving every action yourself, it calls the result arguably a regression.
Two more figures circulate in secondary coverage and are worth labeling as such. News reports describe a controlled study with 1,053 testers in which humans caught 13.6% of a planted dangerous command and the classifier caught 89%. Separate coverage cites an independent evaluation in which none of 720 prompt injection attacks succeeded against auto mode. Read these as Anthropic-reported results relayed by journalists, not as numbers from an independent audit.
Auto Mode Is Now Often the Default
The permission modes page says that with Claude Code v2.1.283 or later, auto mode is the built-in starting permission mode for interactive terminal and VS Code sessions. News coverage dates the change for Pro, Max, and Team plans to August 14, 2026. Auto mode requires a supported model, and administrators can switch it off with permissions.disableAutoMode. Non-interactive claude -p runs and Agent SDK runs start in Manual mode unless you set a mode.
Auto mode has its own safety rails. When this mode is activated, Claude Code removes permissive rules that allow unrestricted code execution, such as Bash(*). This lets the classifier evaluate commands that could pose the greatest risk. If the classifier blocks an action three times in a row, or twenty times in total, auto mode pauses and prompting resumes. The docs add a warning: auto mode reduces permission prompts but does not guarantee safety.
One detail from the docs’ block list is a nice illustration of how the two ideas relate. Among the actions the classifier blocks by default is launching an autonomous agent loop that runs without human approval or a sandbox, such as one started with --dangerously-skip-permissions. In short, Auto mode treats an attempt to launch a bypass-mode agent as a potentially risky action.
Permission Modes Compared
Here is how the six documented modes compare, from the permission modes page:
| Mode | What runs without asking | Best for |
|---|---|---|
default (Manual) | Reads only | Sensitive work, unfamiliar code |
acceptEdits | Reads, file edits, common filesystem commands | Iterating on code you review afterward |
plan | Reads, plus classifier-approved commands when auto is available | Exploring before changing |
auto | Everything, with background safety checks | Long tasks, reducing prompt fatigue |
dontAsk | Pre-approved tools only; the rest is denied | Locked-down CI and scripts |
bypassPermissions | Everything | Isolated containers and VMs only |
The docs’ “common setups” table pairs goals with settings. For fully unattended runs inside a container, it suggests claude -p "<prompt>" --dangerously-skip-permissions and marks isolation as required. For CI with an exact allowlist, it suggests --permission-mode dontAsk with --allowedTools, which needs no isolation beyond what the runner provides. That second pattern is worth knowing, because many pipelines reach for the bypass flag when a tight allowlist would do.
Scripts, CI, and the Agent SDK
Non-Interactive Runs
In a claude -p run, no confirmation dialog appears, and the few calls that would still prompt are denied instead. That makes the headless case predictable but strict: ask rules and critical-path removals do not pause for you, they fail. For many scripts that is the right behavior.
With Claude Code v2.1.302 or later, claude -p and Agent SDK runs with no permission mode set start in Manual mode, so calls needing approval are denied unless an allow rule, hook, or callback approves them. If you never intended to skip prompts, this default is a sensible baseline.
The Agent SDK
The SDK exposes the same mode as bypassPermissions. Its documentation says all tools run without prompts, that Claude has full system access, and that allowed_tools does not constrain this mode. In TypeScript, the mode also requires allowDangerouslySkipPermissions: true, and it cannot be enabled when running as root on Unix.
Two SDK facts matter for design. Deny rules are checked first and hold in every mode, so they remain your guardrail. And when the parent uses bypassPermissions, acceptEdits, or auto, all subagents inherit that mode and it cannot be overridden per subagent. If you delegate work to subagents, assume they carry the parent’s lack of prompts.
Controls for Teams and Administrators
You do not have to rely on every developer making the right call. The documented controls include:
| Control | Effect |
|---|---|
permissions.disableBypassPermissionsMode: "disable" | Prevents bypass mode from being activated; works in any settings file and is typically set in managed settings |
permissions.disableAutoMode: "disable" | Removes auto mode from the cycle |
--restricted | Refuses bypass mode in that session (v2.1.248 or later) |
| Desktop organization policy | On Team and Enterprise plans, controls whether the Bypass toggle exists |
| Project settings ignore | A checked-in defaultMode of bypass or auto does not take effect |
For regulated environments, the HIPAA configuration keeps bypass available but lets administrators block it with the same managed setting. If your organization has any policy against unattended agents on developer laptops, set the disable flag first and grant exceptions through isolated environments.
A Practical Checklist Before You Skip Permissions
The following steps follow from the documentation and are written as a planning aid, not a guarantee.
- Decide whether you need it. If the goal is fewer prompts, compare
acceptEdits, auto mode, and the Bash sandbox’s auto-allow mode first. - Choose a boundary. Container, VM, or sandbox runtime, covering file tools, MCP servers, and hooks.
- Run as a non-root user. The CLI refuses root and
sudooutside a recognized sandbox. - Limit what is mounted. Mount only the project. Leave SSH keys, cloud credential files, and browser profiles out.
- Restrict outbound traffic. Use a default-deny firewall with a short allowlist.
- Write deny rules. A few rules for destructive commands apply even in bypass mode.
- Work on a branch. Version control makes in-project damage reviewable and reversible.
- Cap the run. For scripted use, set turn and budget limits in the SDK, or rely on a disposable environment.
- Keep secrets out of reach. Use short-lived, narrowly scoped credentials, if any.
- Review the diff afterward. Skipping prompts moves review to the end, so make that review real.
Common Mistakes and Troubleshooting
| Problem | Likely cause | What the docs suggest |
|---|---|---|
Session starts in Manual despite defaultMode: "bypassPermissions" | The value sits in project settings, which are ignored for bypass | Move it to ~/.claude/settings.json or use a flag |
| Flag refused as root | Claude Code blocks bypass for root or sudo outside a sandbox | Run as a non-root user, or use the dev container |
| Background session ignores the bypass request | Acceptance is missing from user or managed settings | Add skipDangerousModePermissionPrompt: true to ~/.claude/settings.json |
| Bypass option missing in VS Code | The extension toggle is off | Enable “Allow dangerously skip permissions” |
| Bypass option missing in Desktop | Plan or organization policy | Pro and Max: settings toggle; Team and Enterprise: ask your admin |
| A deletion still prompts | Critical-path check or ask rule | Name the exact path, use a literal path, or approve the prompt |
| Cloud session never goes into bypass | Cloud sessions do not offer it | Use auto mode or Accept edits there |
| Typo-style settings keys have no effect | Unknown keys are silently ignored | Use permissions.defaultMode |
If permission settings or other configuration problems prevent Claude Code from working as expected, see our guide to Claude Code common errors and fixes
When Skipping Permissions Makes Sense, and When It Does Not
The documentation’s guidance supports a simple split. The flag fits disposable, well-isolated environments: a throwaway container, a CI job with no secrets, a VM you can wipe. It fits poorly on your main laptop, in a repository with production credentials in reach, or anywhere the agent can read content you did not write, such as arbitrary web pages and third-party repositories.
A useful test is to ask what the worst action inside the boundary would cost. If the answer is “I would delete a container and start again,” bypass mode is reasonable. If the answer includes a leaked token or a changed shared resource, the boundary is not tight enough.
If you are evaluating autonomous coding tools partly on their isolation and security models, our Codex vs Claude Code comparison provides additional context.
Where This Is Heading
The public record suggests three trends. Anthropic is steering everyday use toward auto mode and away from approval prompts, and its own materials describe bypass mode as unsafe in most situations. Guardrails around the flag keep growing, from the non-root refusal to project-settings restrictions and the --restricted option. And isolation is becoming first-class, with the sandbox runtime and the reference dev container documented alongside the permission modes. Expect names, defaults, and version thresholds to keep shifting, and verify against the changelog before you standardize on a configuration.
Frequently Asked Questions (Claude Code –dangerously-skip-permissions)
Q: What does claude –dangerously-skip-permissions do?
A: It starts Claude Code in bypassPermissions mode, so tool calls run without routine permission prompts. Deny rules, explicit ask rules, and a few other checks still apply.
Q: Is –dangerously-skip-permissions the same as bypassPermissions?
A: Per the official docs, yes. The flag is equivalent to --permission-mode bypassPermissions. Some community guides call it deprecated, but the documentation does not.
Q: Is it safe to use?
A: Not by itself. Anthropic’s documentation says to run it only in isolated environments such as containers or VMs, and its engineering article calls the flag unsafe in most situations.
Q: Can I turn it on in a project’s settings file?
A: No. A bypassPermissions default in .claude/settings.json or .claude/settings.local.json does not take effect, and the session starts in Manual mode. Use your user settings, a --settings file, or managed settings.
Q: Why does Claude Code refuse the flag as root?
A: On Linux and macOS, it refuses bypass mode under root or sudo for security reasons, unless it detects a recognized sandbox.
Q: What still prompts in bypass mode?
A: Explicit ask rules, rm and rmdir on critical paths, tools that require user interaction, organization-controlled connector tools, and a few other safeguards listed in the permission modes page.
Q: How is auto mode different?
A: Auto mode keeps a classifier reviewing each action, so risky ones can be blocked. Anthropic reports a 17% miss rate on real overeager actions, so it reduces risk without eliminating it.
Q: Can an administrator block the flag?
A: Yes. Setting permissions.disableBypassPermissionsMode to "disable" prevents the mode from being activated, and on Team and Enterprise plans the desktop toggle is governed by organization policy.
Q: Does it work in Claude Code on the web?
A: No. Cloud sessions offer Accept edits, Plan, and Auto, but not Bypass permissions, and they ignore bypass defaults from settings files.
Q: Do subagents inherit bypass mode?
A: In the Agent SDK, yes. The docs say subagents inherit the parent’s mode when it is bypassPermissions, acceptEdits, or auto, and it cannot be overridden per subagent.
Conclusion on Claude Code –dangerously-skip-permissions
Claude Code dangerously-skip-permissions is best understood as a trade. You give up the per-action pause, and in return you get uninterrupted work. The documentation is consistent about the price: a mode that skips prompts and protected-path checks, with only a short list of safeguards left, and an isolation boundary as the main thing limiting damage.
Three habits follow. Treat the environment as the safety control, not the flag. Prefer narrower tools, such as acceptEdits, the Bash sandbox, dontAsk with an allowlist, or auto mode, whenever fewer prompts is the real goal. And let administrators set the policy, with disableBypassPermissionsMode as the backstop.
The tooling around this flag changes quickly, so the specifics here, from version thresholds to default modes, deserve a check against the live documentation before you build a workflow on them. Paired with isolation, deny rules, and a review step at the end, the flag has a legitimate place. Without them, the name is a fair warning.