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

> claude --dangerously-skip-permissions starts bypassPermissions. The --allow variant only enables mode selection; neither confines filesystem or network access. Use explicit modes and check how your surface restores sessions.

- URL: https://blog.laozhang.ai/en/posts/claude-code-dangerously-skip-permissions
- Published: 2026-05-07
- Updated: 2026-10-08
- Author: LaoZhang AI Team (https://blog.laozhang.ai/en/about)
- Topic: Claude Code
- Tags: Claude Code, Permission Modes, AI Coding, Developer Tools, Security

---
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](https://code.claude.com/docs/en/permission-modes).

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:

```bash
claude --dangerously-skip-permissions
```

```bash
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](https://code.claude.com/docs/en/cli-reference), [launch checks](https://code.claude.com/docs/en/permission-modes).

This third command has a different result:

```bash
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](https://code.claude.com/docs/en/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](https://code.claude.com/docs/en/permission-modes).

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](https://code.claude.com/docs/en/permission-modes) preserves several exceptions:

| Condition | What happens in Bypass |
| --- | --- |
| An explicit `ask` rule matches | The call still requires approval |
| A tool requires user interaction, or an organization connector policy requires asking | The interaction requirement remains |
| Cross-session messaging triggers a safeguard | The messaging safeguard remains |
| A critical `rm` or `rmdir` check applies | The removal can still require confirmation |
| `blockReadsOutsideWorkingDirectories` applies to a recognized read | Its outside-directory check remains, with documented sandbox exceptions |
| The OS or an outer sandbox refuses access | Bypass cannot grant that access |

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](https://code.claude.com/docs/en/permissions).

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](https://code.claude.com/docs/en/permission-modes):

| Your goal | Start with | Behavior to expect |
| --- | --- | --- |
| Review actions in unfamiliar code | Manual: `default` | Reads and already approved operations can proceed; actions needing approval ask |
| Investigate before changing source | `plan`, with Bypass unavailable in an interactive terminal | Enforced planning restrictions apply within the documented surface conditions |
| Stop approving routine file changes | `acceptEdits` | Approves edits and common in-scope filesystem shell operations; it does not approve every command |
| Let a classifier review tool actions | `auto`, when available | Reduces ordinary prompts but retains classifier and policy decisions |
| Run only operations that can proceed without a prompt | `dontAsk` | Denies calls that would require approval instead of approving them |
| Approve ordinary calls by default in a confined environment | `bypassPermissions` | Relies heavily on the environment's access limits |

For routine edits, the explicit launch is:

```bash
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:

```bash
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](https://code.claude.com/docs/en/cli-reference), [permission rules](https://code.claude.com/docs/en/permissions).

`--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](https://code.claude.com/docs/en/permission-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:

```json
{
  "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](https://code.claude.com/docs/en/permission-modes).

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](https://code.claude.com/docs/en/cli-reference).

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

![Conceptual Claude Code surface comparison linking CLI, VS Code, Desktop, cloud and Remote Control to their own mode controls and execution host](https://blog.laozhang.ai/posts/en/claude-code-dangerously-skip-permissions/img/explainer-3.webp)

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](https://code.claude.com/docs/en/permission-modes):

| Surface | Where the choice comes from | What to check |
| --- | --- | --- |
| Local CLI or JetBrains terminal | CLI launch flags, applicable settings, built-in default | Confirm the actual active mode and version |
| VS Code chat extension | Its user initial mode, eligible remembered mode, then applicable managed/user defaults and built-in default | Bypass requires the extension's enabling toggle; project settings never supply its starting mode |
| Desktop Code | Mode selector, remembered folder choice, and applicable policy | Pro/Max has a Bypass toggle; Team/Enterprise can require organization permission; Cowork is a separate surface |
| Web cloud session | Accept edits, Plan, or eligible Auto | Bypass cannot be selected; repository Bypass and `dontAsk` defaults are ignored |
| Remote Control app | Remote controls plus the existing terminal's execution mode | The app cannot select Auto or Bypass, but its displayed label can differ from the terminal's actual mode |

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](https://code.claude.com/docs/en/sandbox-environments).

## Does --continue keep bypass permissions?

Restoring a saved transcript and reconnecting to a still-running session are different operations. The [documented resume rules](https://code.claude.com/docs/en/sessions#permission-mode-on-resume) are:

| How you return to the work | Permission-mode behavior |
| --- | --- |
| Reconnect to an actual running background session | Keeps that session's mode |
| Restore an interactive transcript by exact ID, name, or `--continue` | Generally restores its mode, but stored Bypass and Plan reset to the new-session starting mode |
| Choose a session from the picker at launch | Uses the new-session starting mode |
| Use `/resume` inside a session | Keeps the current session's mode |
| Resume with `-p` | Uses new print-session defaults, with a versioned Plan-restoration exception requiring a prompt tool and additional conditions |

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

```bash
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

![Conceptual full-process isolation boundary controlling mounts, network, credentials and output, with a smaller command-only sandbox inside](https://blog.laozhang.ai/posts/en/claude-code-dangerously-skip-permissions/img/explainer-2.webp)

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](https://code.claude.com/docs/en/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](https://code.claude.com/docs/en/sandboxing) 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](https://code.claude.com/docs/en/devcontainer) 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:

| Symptom | Check first | Next action |
| --- | --- | --- |
| `--allow-dangerously-skip-permissions` did not stop prompts | It enables selection without choosing Bypass | Inspect the active mode; choose deliberately rather than adding more flags |
| Bypass still shows a tool approval | Explicit ask rules, required interaction, connector policy, critical removal, or outside-directory checks | Identify the matching rule or safeguard; preserve it unless the task requires a separately justified change |
| Claude says “Should I proceed?” in its answer | Model clarification versus a client permission dialog | Clarify the task or next action; changing permission mode cannot guarantee that the model stops asking questions |
| Bypass disappeared after `--continue` | Transcript restoration resets stored Bypass | Check the new environment before explicitly selecting a mode again |
| Root/`sudo` launch is refused | Linux/macOS launch guard | Use the intended non-root account in the prepared environment |
| Bypass is absent in web cloud | That surface does not offer it | Use a supported cloud mode; this is not a missing local CLI flag |
| Project JSON is ignored by VS Code at startup | Extension starting mode ignores project settings | Inspect extension user settings, remembered mode, and managed policy |
| `--restricted` rejects Bypass | From v2.1.248, restricted mode refuses Bypass | Keep restricted mode if confinement is the goal; choose a compatible permission mode |
| A call fails with authentication, quota, model, or provider errors | Service access rather than tool approval | Diagnose the service error; Bypass does not repair credentials, access, or billing |

These checks follow the [mode reference](https://code.claude.com/docs/en/permission-modes) and [CLI reference](https://code.claude.com/docs/en/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](https://code.claude.com/docs/en/permission-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](https://code.claude.com/docs/en/permission-modes).

### 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](https://code.claude.com/docs/en/devcontainer), [process boundaries](https://code.claude.com/docs/en/sandbox-environments).

### 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](https://code.claude.com/docs/en/permission-modes).

### 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](https://code.claude.com/docs/en/permission-modes).

## Sources

External pages this guide links to, in the order they appear. Last updated 2026-10-08.

- [Anthropic documents the flag and modes here](https://code.claude.com/docs/en/permission-modes) (code.claude.com)
- [CLI options](https://code.claude.com/docs/en/cli-reference) (code.claude.com)
- [Rule evaluation and mod exceptions](https://code.claude.com/docs/en/permissions) (code.claude.com)
- [Execution and isolation boundaries](https://code.claude.com/docs/en/sandbox-environments) (code.claude.com)
- [documented resume rules](https://code.claude.com/docs/en/sessions) (code.claude.com)
- [built-in sandbox](https://code.claude.com/docs/en/sandboxing) (code.claude.com)
- [official Dev Container Feature](https://code.claude.com/docs/en/devcontainer) (code.claude.com)