Claude Code --dangerously-skip-permissions: Commands and Safer Modes

To start Claude Code with ordinary permission prompts bypassed, use claude --dangerously-skip-permissions. It selects the same mode as claude --permission-mode bypassPermissions. The flag does not create a sandbox, grant operating-system privileges, or fix authentication. For routine development on your laptop, acceptEdits, explicit tool approvals, or eligible Auto mode can remove the interruptions you actually want to remove without approving everything by default. Anthropic documents the flag and modes here.

The important distinction is between permission to act and the resources the process can reach. Bypass changes the former. Filesystem restrictions, network restrictions, credentials, and the authority of connected tools determine the latter. The behavior below follows the documentation checked on October 7, 2026; version conditions are attached to the cases they change. The examples are documented configurations, not results from a live bypass or containment test.

The command, the --allow variant, and the Plan trap

In an already prepared, disposable environment with deliberately limited host access, either of these launches selects Bypass permissions:

claude --dangerously-skip-permissions

claude --permission-mode bypassPermissions

These are equivalent alternatives, so there is no need to combine them. Use the exact spelling and capital P in bypassPermissions; abbreviated strings such as --bypass are not documented substitutes. Normal login, account access, model availability, and operating-system permissions still apply. On Linux and macOS, use the intended non-root account: Bypass normally refuses root or sudo starts, with a recognized-sandbox exception. --restricted refuses Bypass from v2.1.248. CLI options, launch checks.

This third command has a different result:

claude --permission-mode default --allow-dangerously-skip-permissions

It starts in Manual mode and makes Bypass available for later mode selection. --allow-dangerously-skip-permissions enables that choice; it does not activate it. Without an explicit starting mode, the applicable settings and built-in default determine where you start. Inspect the active mode rather than inferring it from the presence of the word “allow.” Permission modes.

There is a consequential Plan exception: in an interactive terminal, making Bypass available also removes Plan's enforced edit and command blocks. Claude still receives instructions to plan, but those instructions are not a read-only boundary. A launch that combines --permission-mode plan with the --allow flag therefore cannot promise enforced read-only work. Plan retains its enforced blocks in print mode (-p), SDK sessions, and VS Code chat sessions. If your purpose is investigation without edits, keep Bypass unavailable in the interactive terminal. Current Plan behavior.

The first interactive Bypass launch also has a responsibility warning. Accepting that warning is recorded separately from choosing the active mode. Print mode does not display the warning dialog, while background startup with --bg requires prior acceptance. Absence of a dialog in an unattended run is not proof that the environment is isolated.

What bypass skips—and what can still stop it

Current Bypass normally approves tool calls immediately, including writes to protected paths. Older descriptions that promise a prompt for every protected configuration write no longer describe the current mode. However, “bypass permissions” does not mean “nothing can ever interrupt or reject a call.” The mode documentation preserves several exceptions:

Since v2.1.281, critical removal prompts in terminal Auto and Bypass have a two-minute limit; repeated unanswered prompts result in denial. Nonterminal Auto denies those critical removals. PowerShell system-path and wildcard removals have separate denials across modes. These are specific command checks, not a guarantee that every destructive operation will be intercepted. Keep valuable files out of reach rather than designing around the last confirmation prompt.

Ordinary permission rules are evaluated in deny, ask, allow order across settings scopes. A matching deny blocks the call; an allow cannot cancel it. Bypass does not make an ordinary allow rule more restrictive. A PreToolUse hook can also block a call in Bypass, subject to the extension exception that follows. An installed in-process mod with tool.check can replace ask, hook, or classifier decisions and, under documented policy conditions, some deny decisions. Managed hook blocks and Team, Enterprise, or managed deny policies have specific protections. If a mod is installed, do not assume the unmodified permission evaluator is the only code making the decision. Rule evaluation and mod exceptions.

A shell rule also has a narrower job than an OS boundary. It matches recognized command text and wrappers, not every indirect program that can perform the same operation. A Read denial alone cannot stop every shell subprocess from reading that file. Use rules to express approval policy; use process isolation to constrain access.

Safer alternatives that solve different interruptions

Choose a mode by the result you want, rather than treating them as successive levels of “never ask.” According to the current permission-mode reference:

For routine edits, the explicit launch is:

claude --permission-mode acceptEdits

This is broader than “Edit and Write only”: common filesystem commands within scope can also proceed. It is still different from permitting arbitrary shell execution. Outside-directory, protected-path, symlink, and critical-operation checks can change the result.

For an unattended task that should produce an answer from a known file, a narrower documented example is:

claude -p --permission-mode dontAsk --tools "Read" --disallowedTools "mcp__*" \
  "Read README.md and report the setup steps. Do not change files."

This assumes a readable README.md in the intended working directory and a configured client. --tools "Read" selects that built-in tool; the separate MCP denial matters because --tools does not restrict MCP tools. dontAsk lets permitted reads proceed and denies actions that require approval. A denial can leave the task incomplete; it is not automatically an error that you should fix by widening permissions. Existing hooks and helpers still need their own controls, so this command is not full-process isolation. CLI tool selection, permission rules.

--allowedTools is another source of confusion. It preapproves matching operations; it does not mean every unlisted tool is unavailable. Use --tools for selecting built-in tools, separate MCP restrictions when needed, and an outer boundary for filesystem or network capabilities.

Is Auto available on my plan, and is it the default?

Current documentation no longer supports a blanket “Pro cannot use Auto” rule. Since v2.1.283, the built-in starting mode for interactive terminal and VS Code sessions is Auto across plans and providers, subject to supported models, provider-specific model minima, administrator policy, and server availability checks. An explicit launch mode or applicable setting can override that default. Auto availability and starting modes.

Print-mode and SDK defaults differ. Sessions that fetch feature flags normally start in Manual; sessions without flag fetching default to Auto from v2.1.285, subject to availability and policy. HIPAA-eligible organizations have a separate Manual default. If your automation depends on a specific approval policy, pass a mode explicitly rather than relying on the default of whichever client starts it.

Auto is classifier review, not containment. A model or provider mismatch, disabled policy, or unavailable verdict can prevent the expected behavior. In -p without a permission-prompt tool, documented classifier fallback denies affected calls and continues; it does not guarantee approval or terminate every run. Likewise, do not treat Auto as a universal prohibition on pushing to the default branch: the docs no longer describe that blanket block from v2.1.211. Repository protection and credentials must enforce important release boundaries.

Persistent settings: choose the scope before the default

For a CLI user who wants a predictable Manual start, the relevant JSON fragment for the user settings file, ~/.claude/settings.json, is:

{
  "permissions": {
    "defaultMode": "default"
  }
}

Merge the permissions.defaultMode field into an existing file rather than replacing unrelated settings. default is the configuration value for the UI's Manual label; manual is also accepted from v2.1.200. This example sets a starting mode—it neither disables all existing approvals nor creates a filesystem policy. An explicit --permission-mode at launch takes priority, and managed policy can constrain the choices. Starting-mode precedence.

For fewer routine edit prompts, the same user-level field can be set to acceptEdits. Do not put auto or bypassPermissions in repository settings and expect them to become the starting mode: project defaults for those values do not take effect, and a project Bypass default starts in Manual. User, managed, and explicit --settings values have different scopes. An explicit settings file also overlays its specified keys; it does not erase every other setting or authority the process has. CLI settings options.

In an interactive session, /permissions provides an inspection point for permission rules. If the observed mode differs from your JSON, check the launch flags, the settings scope, and the surface's starting-mode rules before modifying anything else. Avoid hiding a global bypass flag inside an everyday claude alias: it makes a new terminal session inherit a major decision without an obvious reminder.

Surface matrix: CLI, VS Code, Desktop, and Remote Control

The executable behind a terminal, an editor chat, and a remote app do not necessarily share starting-mode controls. The following distinctions come from the official interface-specific tabs:

For VS Code, do not assume its initial-mode setting and remembered selection cover every mode: remembered Manual, Edit, and Auto choices have documented rules, while Plan and Bypass are not remembered in the same way. Wrapper launch conditions can also affect the order. Check the current extension controls rather than trying to fix an editor-chat issue with a repository default.

For Remote Control, “the phone cannot select Bypass” does not prove “the remote session always executes in Manual.” Check the terminal where the session runs. Remote control also does not make Claude Code offline: prompts and file content used for inference still go to the configured model provider. Execution and isolation boundaries.

Does --continue keep bypass permissions?

Restoring a saved transcript and reconnecting to a still-running session are different operations. The documented resume rules are:

To deliberately restore the latest terminal transcript with Bypass active again, the documented launch combination is:

claude --continue --dangerously-skip-permissions

Use that only after checking that the new process still runs in the intended confined environment. It explicitly reselects Bypass; --continue by itself is not a promise to retain it. A previously isolated process, an old acceptance dialog, or a branch name does not establish the boundary of this new launch.

Isolation checklist before an unattended bypass run

For full Bypass, use a boundary around the whole process—an appropriately configured container, VM, or full-process sandbox runtime. The official runtime is currently a beta research preview requiring explicit filesystem and network configuration. A Git worktree separates repository changes; it does not separate OS access. Container bind mounts can still edit host files, inherited credentials can still authorize services, and a mounted Docker socket can grant control beyond the workspace. Sandbox environments.

A practical preparation sequence is:

1. Limit the data supplied. Provide a copy of the repository and only the state the task needs. Keep host home directories, production credentials, SSH keys, cloud credentials, and Docker sockets out of the environment. Review intended mounts and environment-variable names without dumping secret values into logs.
2. Limit where data can go. Permit only required model/authentication endpoints and task-specific destinations. An allowed destination can still receive data the process can read; filesystem controls and network controls must work together. Claude Code's remote inference still needs its configured provider, so “offline container” is not a working cached-model promise.
3. Choose a supported non-root execution account. On Linux and macOS, Bypass normally refuses root or sudo starts, with a recognized-sandbox exception. The official container guidance uses a non-root account. Do not respond to a refusal by disabling the guard.
4. Verify the intended policy is loaded before enabling Bypass. Missing configuration, an apparently successful start, or the mere existence of a container does not establish the configured boundary. Verify filesystem and network enforcement in an authorized disposable environment, without testing against real secrets or production systems.
5. Keep an inspectable output and a review gate. Use a separate diff and task-appropriate checks before integrating changes. Git can recover tracked content; it cannot undo a leaked token, an external deployment, or damage to a writable bind mount.

Why the built-in command sandbox is not enough by itself

Claude Code's built-in sandbox covers Bash, PowerShell, Monitor, and their child processes. It does not surround file/web tools, MCP tools, hooks, LSP, status-line helpers, mods, or screen control. It is off by default. macOS, Linux, and WSL2 have supported implementations; native Windows does not have this sandbox.

Two settings solve different escape paths. sandbox.failIfUnavailable prevents unsupported or missing-dependency startup from silently falling back to unsandboxed commands. sandbox.allowUnsandboxedCommands: false disables the retry escape hatch, but excluded commands and other tool types still need attention. From v2.1.285, a user-level false holds against a project-level true; managed or CLI strict policy can make sandboxing required without enabling it by itself. “Auto-allow sandboxed commands” is also a different setting from the Auto permission classifier.

Network configuration needs special care in Bypass: an empty sandbox.network.allowedDomains list does not alone block all outbound hosts. Unlisted hosts can be approved automatically unless strictAllowlist or a managed domain lock constrains them. Default reads and inherited environment variables can also include credentials unless explicitly restricted. These defaults are why a copied sandbox fragment should never be called a complete isolation recipe.

The official Dev Container Feature installs Claude Code; adding it alone does not install a default-deny firewall. Its :1.0 tag pins the feature's installation script, not the Claude Code release. The reference's devcontainer.json, Dockerfile, and firewall script are a working example requiring adaptation, not a maintained base image. Review writable workspace mounts and persistent configuration volumes: retained configuration can also retain authentication and history.

Troubleshooting: why it still prompts or does not appear

Start with the symptom, then take the smallest corrective step:

These checks follow the mode reference and CLI reference. Avoid widening permissions merely because a run is incomplete. First distinguish an intentionally denied tool call from a launch problem, a missing boundary, or an unrelated service failure.

FAQ

Is --dangerously-skip-permissions the same as bypassPermissions?

Yes. claude --dangerously-skip-permissions and claude --permission-mode bypassPermissions select the same mode. The separate --allow-dangerously-skip-permissions flag only makes Bypass available for selection. Official modes.

Does dontAsk give Claude all permissions without asking?

No. dontAsk denies calls that would need approval while retaining permitted reads, preapproved operations, and permitted hook decisions. Use it when denial is acceptable; use explicit tool selection when you also need to remove tool capabilities. Required-interaction calls and applicable explicit ask rules are denied. Mode behavior.

Is Docker enough to make bypass safe?

Only a deliberately configured boundary limits the damage. Writable host mounts, mounted credentials, a Docker socket, or broad outbound access can preserve substantial authority. The installation feature supplies Claude Code, not a default-deny firewall. Verify the actual configuration before relying on it. Container guidance, process boundaries.

Does bypass protect against prompt injection?

No. Skipping ordinary approval checks does not make instructions in repositories, fetched content, or tool output trustworthy. Isolation limits what a mistaken action can reach; it does not ensure the model always follows the intended task. Permission-mode guidance.

Can I use it for CI without an interactive warning?

Print mode does not show the interactive Bypass warning, but that does not make a credential-bearing CI runner an appropriate boundary. Separate code changes from publishing and deployment, restrict process access, and select the permission mode explicitly. If the task can work with denied unapproved actions, dontAsk is a narrower starting point. CLI and print-mode behavior.