Original URL: https://getagenttools.com/blog/dangerously-skip-permissions/

# --dangerously-skip-permissions: what it skips, what still stops Claude, and the dead allowlist

Updated 17 Oct 2026Marek.

- claude-code
- agent-security
- agent-ops

`--dangerously-skip-permissions` is the Claude Code flag that starts a session in `bypassPermissions` mode, where tool calls run without a permission prompt, bar a short list. The prompts it removes are the obvious part. The less obvious part is the allowlist it turns into dead weight, and the two layers it leaves standing.

  

- **What it is.** The CLI reference: "Skip permission prompts. Equivalent to `--permission-mode bypassPermissions`". Status bar: `⏵⏵ bypass permissions on`.
- **What it does not skip.** Among others: deny rules from any settings file, explicit ask rules, the `rm` circuit breaker on critical paths, and a [PreToolUse hook](https://getagenttools.com/blog/pretooluse-hook/) that says no.
- **What it makes irrelevant.** Every allow rule. Under the flag the allowlist decides nothing, even when it holds hundreds of saved commands with tokens inside.
- **Where it dies.** `claude --resume` from a terminal. A session that ended in bypass comes back in the mode a new session would start in.
- **The verdict.** TESTED. Right for a throwaway container. Wrong as the default on the machine that holds the credentials.

 

A skill's [disable-model-invocation](https://getagenttools.com/blog/disable-model-invocation/) flag hides that skill from the model, the [PreToolUse hook](https://getagenttools.com/blog/pretooluse-hook/) reads every command before it runs, and permission modes decide who answers the prompt in between. In a [Claude Code](https://getagenttools.com/tools/claude-code/) setup this flag turns that "who" into "nobody".

 

## What does --dangerously-skip-permissions do?

 

It starts Claude Code in `bypassPermissions` mode. The [permission modes page](https://code.claude.com/docs/en/permission-modes) gives that mode one line. It "disables permission prompts and safety checks so tool calls execute immediately, including writes to protected paths". In an interactive terminal that covers ordinary file edits, shell commands and network calls. Writes to `.git` or `.claude` run without a prompt too. The exceptions below still apply. `claude -p` handles this differently. A call that still needs a prompt, and that no allow rule or hook resolves, is denied when there is no permission host. With a configured host it waits, unless you pass `--permission-prompts none`.

 

The [CLI reference](https://code.claude.com/docs/en/cli-reference) lists `--permission-mode bypassPermissions` as the equivalent form; both override a `defaultMode` from settings for one session. The whole argument sits in one sentence on the modes page: `bypassPermissions` "offers no protection against prompt injection or unintended actions". Manual mode puts me in front of the action, auto mode a classifier, bypass nothing.

 

## What the flag does not skip

 

The docs keep a short list of actions "no mode auto-approves", and bypass is named in that sentence. Everything below still fires with the flag on, unless a mod that handles `tool.check` is installed (v2.1.292+), which per the [permissions page](https://code.claude.com/docs/en/permissions#extend-permissions-with-hooks) can change ask, deny and unmanaged-hook outcomes. The list is not exhaustive; the [modes page](https://code.claude.com/docs/en/permission-modes#skip-all-checks-with-bypasspermissions-mode) keeps the current set.

 

| Still active under the flag | Per the docs |
| --- | --- |
| Deny rules from any scope, `--disallowedTools` included | "Deny rules block in every mode, including `bypassPermissions`" |
| Explicit ask rules such as `Bash(git push *)` | Still prompt; first on the no-mode-auto-approves list |
| `rm` or `rmdir` on a critical path: root, home, the working directory and its parents | Bypass "Asks you to approve it"; no allow rule or hook `"allow"` clears it |
| `AskUserQuestion`, MCP tools marked `requiresUserInteraction`, connector tools set to `ask` | Prompt under the flag |
| Recognized reads outside working directories when `permissions.blockReadsOutsideWorkingDirectories=true` | Prompt even under bypass; the sandbox can deny the read instead |
| A `PreToolUse` hook that denies or exits 2 | A hook `deny` "blocks the tool even in `bypassPermissions` mode", per the [hooks guide](https://code.claude.com/docs/en/hooks-guide) |
| Root and `sudo` on Linux and macOS | Refuses to start, unless inside a recognized sandbox |

 

Modes decide whether Claude asks. The sandbox decides what an action can reach once it runs. First thing the flag drops that other modes mostly keep: the protected-path list. Writes to `.git`, `.claude`, `.vscode`, the shell rc files and `.mcp.json` are auto-approved in `bypassPermissions` mode. Per the current [modes page](https://code.claude.com/docs/en/permission-modes#available-modes), the same goes for interactive plan mode when bypass is in the cycle. The human is gone. Most safety checks too. Deny rules, ask rules, the critical-path breaker and hook denies are among what stays.

 

## How to use dangerously skip permissions?

 

Pass the flag at launch. That is `claude --dangerously-skip-permissions`, or the equivalent `claude --permission-mode bypassPermissions`. The first interactive start shows a dialog. It asks you to accept responsibility. Accepting writes `skipDangerousModePermissionPrompt: true` to your user settings. After that the dialog never returns. Shift+Tab reaches the mode only in a session that started with it available.

 

`--allow-dangerously-skip-permissions` is the softer variant: it adds `bypassPermissions` to the Shift+Tab cycle "without starting in it", so a session can begin in plan mode and switch once the plan is approved. The catch: In an interactive terminal with bypass in the cycle, plan mode stops enforcing its blocks, and "a file edit or shell command it attempts during planning runs without prompting". This does not apply to non-interactive runs such as `claude -p`. Non-interactive runs show no dialog at all.

 

### `claude --dangerously-skip-permissions` by default

 

The documented key is `permissions.defaultMode`, and for this value the [settings reference](https://code.claude.com/docs/en/settings-reference) counts only `~/.claude/settings.json`, `--settings` or managed settings:

 

```json
{
  "permissions": {
    "defaultMode": "bypassPermissions"
  }
}
```

 

In a project's `.claude/settings.json` or `.claude/settings.local.json` the same value "doesn't take effect" and "the session starts in Manual mode". Before v2.1.257 it worked from any file, so older project configs stopped working then.

 

Do not read `"skipDangerousModePermissionPrompt": true` in user settings as a default. It only skips the warning dialog. Claude Code writes it when you accept that dialog once. It does not start bypass. Want bypass as a default? Use the documented key.

 

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

 

That line is the exact error on Linux and macOS when the process runs as root or under `sudo`. "The check is skipped automatically inside a recognized sandbox", and the docs point to the dev container configuration, which runs Claude Code as a non-root user. The fix is a user account, not a flag.

 

### The alias habit

 

The CLI reference calls `claude` aliased to include the flag "a common setup", in a note on a `daemon` routing bug fixed in v2.1.199. The habit outlives the bug: an alias starts every session on the machine with no permission layer, the repository with the deploy credentials included. Alias `--allow-dangerously-skip-permissions` instead and switch on purpose.

 

### When it is not working

 

Common failures in the docs fall into two groups. Refused: `disableBypassPermissionsMode: "disable"` in managed settings, a `--restricted` session, root, or a `--bg` session before the dialog was accepted interactively. Ignored: `defaultMode` in a project or local file, Claude Code on the web, VS Code with the **Allow dangerously skip permissions** toggle off. A resume does not restore a stored bypass mode, but an explicit launch flag still works; see the resume section below. A [subagent](https://getagenttools.com/blog/claude-code-subagents/) declaring `permissionMode: bypassPermissions` keeps the parent's mode unless the parent is already in bypass, per the [subagents page](https://code.claude.com/docs/en/sub-agents), v2.1.267 and later.

 

## Is auto mode the same as dangerously skip permissions?

 

No. Both remove prompts, but auto mode puts a second model, the classifier, in front of most shell commands and network calls, and blocks deploys, force pushes, sending sensitive data out, and more by default. `bypassPermissions` puts nothing there. The docs say it "offers no protection against prompt injection or unintended actions" and point you to auto mode instead.

 

From v2.1.283, auto mode is the built-in starting mode for interactive terminal and VS Code sessions on all plans and providers, when auto mode is available and organization policy does not override it ([details](https://code.claude.com/docs/en/permission-modes#which-mode-a-session-starts-in)). The classifier sees the pending action and part of the transcript with tool results stripped, and falls back to prompting after three consecutive blocks or twenty in total. On entering auto mode Claude Code drops broad allow rules such as `Bash(*)` and wildcarded interpreters like `Bash(python*)`; narrow rules stay.

 

In auto mode a hook's `ask` still produces a prompt. Under bypass the pages say nothing about it. I have not tested a hook's `ask` under bypass. The classifier's default block list includes "launching an autonomous agent loop that runs without human approval or a sandbox, such as one started with `--dangerously-skip-permissions`". So auto mode treats this flag as something to catch.

 

## Do Codex, Cursor, Copilot, opencode and Gemini CLI have a --dangerously-skip-permissions?

 

Only opencode accepts the name, as a hidden alias of `--auto`; that is in its source, not its docs (checked 17 October 2026). All five have a switch that stops the agent asking. I checked each one in its vendor's docs on 11 October 2026. Four list `--yolo` in their docs. Gemini marks its `--yolo` as deprecated.

 

| Agent | The switch | What it keeps, per the docs |
| --- | --- | --- |
| Claude Code | `--dangerously-skip-permissions` or `--permission-mode bypassPermissions` | Deny rules, ask rules, hook denies, the critical-path breaker, and more |
| Codex CLI | `--dangerously-bypass-approvals-and-sandbox`, or `-a never` with a sandbox ([Codex post](https://getagenttools.com/blog/codex-dangerously-skip-permissions/)) | `-a never` keeps the selected sandbox; the bypass removes both |
| Cursor CLI | `-f, --force`: "Force allow commands unless explicitly denied"; `--yolo` is "Alias for `--force`" | Explicit denies. The IDE's auto-run setting: not checked |
| GitHub Copilot CLI | `--allow-all-tools`; `--allow-all`, alias `--yolo`, equals `--allow-all-tools --allow-all-paths --allow-all-urls`; `/permissions allow-all` in a session, with `/yolo` as an alias | `--deny-tool` sits next to it: "Deny rules always take precedence over allow rules, even when `--allow-all` is set" |
| opencode | `opencode --auto` (hidden aliases `--yolo`, `--dangerously-skip-permissions`), or `"permission": "allow"` in `opencode.json` ([opencode post](https://getagenttools.com/blog/opencode-dangerously-skip-permissions/)) | Explicit `"deny"` rules |
| Gemini CLI | `--approval-mode=yolo`; `--yolo` is "Deprecated. Auto-approve all actions" | Turns the sandbox on: "Sandbox is enabled when using `--yolo` or `--approval-mode=yolo` by default". Deny rules: nothing stated. YOLO "can only be enabled via command line" |

 

### Does Codex have a dangerously skip permissions flag?

 

Not under that name. The closest match is `--dangerously-bypass-approvals-and-sandbox`, which drops approvals and the sandbox together; `-a never` drops only the prompts. Flags, config keys and the `--approve-for-me` conflict are in [Codex dangerously skip permissions](https://getagenttools.com/blog/codex-dangerously-skip-permissions/).

 

### How do I skip permissions in opencode?

 

Start it with `opencode --auto`, or set `"permission": "allow"` in `opencode.json`. `--dangerously-skip-permissions` also works there, as a hidden alias. Explicit deny rules still apply. Details: [opencode --dangerously-skip-permissions](https://getagenttools.com/blog/opencode-dangerously-skip-permissions/).

 

### How do I skip permissions in Cursor CLI?

 

Pass `-f` or `--force`. The [parameters page](https://cursor.com/docs/cli/reference/parameters) reads: "Force allow commands unless explicitly denied". `--yolo` is listed as "Alias for `--force`". Explicit denies still apply under `--force`. The [permissions page](https://cursor.com/docs/cli/reference/permissions) adds "Deny rules take precedence over allow rules". The sandbox has its own flag, `--sandbox <mode>`. I did not check the auto-run setting in the Cursor IDE.

 

### What is the Copilot CLI version of dangerously skip permissions?

 

It is `--allow-all`. The [command reference](https://docs.github.com/en/copilot/reference/copilot-cli-reference/cli-command-reference) calls it "equivalent to `--allow-all-tools --allow-all-paths --allow-all-urls`". `--yolo` does the same thing. Inside a session the command is `/permissions allow-all`. `/allow-all` and `/yolo` "remain supported as aliases". Deny rules still win. The reference says "Deny rules always take precedence over allow rules, even when `--allow-all` is set". Set `permissions.disableBypassPermissionsMode` to `"disable"` and the CLI suppresses these flags at startup. The slash commands are suppressed too.

 

### Does Gemini CLI have a dangerously skip permissions flag?

 

It has YOLO mode. Start it with `--approval-mode=yolo`. The older `--yolo` and `-y` are marked "Deprecated. Auto-approve all actions" in the [CLI reference](https://geminicli.com/docs/cli/cli-reference/). The configuration reference says YOLO "can only be enabled via command line". It also says "Sandbox is enabled when using `--yolo` or `--approval-mode=yolo` by default". A setting named `security.disableYoloMode` turns the mode off "even if enabled by a flag". I found no sentence about deny rules under YOLO.

 

I rechecked the Codex row on 11 October 2026. I used local `codex-cli 0.162.1` (`codex --version` and `codex --help`), the [CLI reference](https://learn.chatgpt.com/docs/developer-commands?surface=cli) and the approval and sandbox docs linked above. This checks the documented contract only. I did not launch bypass or test blocked commands in any of the five. The verdict below covers Claude Code only.

 

opencode's `--auto` is the closest match to Claude Code's contract: prompts gone, denies kept. I did not check Zed or the Copilot agent inside VS Code.

 

## The allowlist it makes irrelevant

 

"Yes, and don't ask again" saves the command you approved as an allow rule. The [permissions page](https://code.claude.com/docs/en/permissions) names the place. The rule lands in `.claude/settings.local.json` at the repository root, "permanently per repository and command". Clicks add up. A busy project can collect hundreds of rules. The rule keeps the command text or its prefix, so a token typed into a command can land in the file. Some can carry a token or an API key.

 

The permission modes page settles what that file is worth under the flag in seven words: "Allow rules have no effect in `bypassPermissions`." So the flag does two things. It removes the prompts. It also turns the allowlist into a file that decides nothing. The secrets in it stay put. Scan it in every audit and trim it to general rules.

 

The allowlist is a log of past clicks, not a [guardrail](https://getagenttools.com/blog/what-are-ai-guardrails/). The guardrails live in `permissions.deny`, which blocks listed tool uses "including reads of files that hold secrets", and in hooks.

 

## What still stops Claude under the flag

 

Two kinds of hook. A soft one matches risky command patterns and answers `ask`. A hard one exits 2 with a message. The [PreToolUse post](https://getagenttools.com/blog/pretooluse-hook/) builds both kinds. The exit-2 hooks on my side, which block production writes, were tested with harmless commands before I relied on them, and the matching ones were stopped live.

 

The docs draw the line between the two under this flag. The hooks guide says a hook `deny` "blocks the tool even in `bypassPermissions` mode"; the [hooks reference](https://code.claude.com/docs/en/hooks) says exit 2 "routes the same way as `"deny"`"; the permissions page adds that an exit-2 hook stops the call "before permission rules are evaluated". A hook's `ask` is a Manual and auto-mode tool. Under bypass the docs say nothing about it, so do not count on it.

 

The costlier lesson is not about hooks. A blocked call does not end the attempt. A blocked Edit can come back as a `sed` one-liner, then as `python -c`. The flag changes nothing about that. Deny rule and hook still fire. The model still looks for another door. The doors it finds are the commands a pattern list does not name. An instruction such as "do not route around a block by switching tools" can help. It is text, not enforcement.

 

Before allowing a broader command path, [test Claude Code sandbox file and network boundaries](https://getagenttools.com/blog/claude-code-sandbox/) and record which tools execute outside that boundary.

 

## Why it does not survive --resume

 

Per the [sessions page](https://code.claude.com/docs/en/sessions), a session that ended in `bypassPermissions` and is resumed from a terminal with `claude --continue` or `claude --resume` comes back in "the permission mode a new session would start in". Current docs restore plan under the conditions listed there; bypass is not restored. To get bypass back, "enable it at launch with one of its launch flags" or set the documented `defaultMode`.

 

The session picker and `/resume` follow the same rule for bypass; the [sessions page](https://code.claude.com/docs/en/sessions#permission-mode-on-resume) lists when they and `claude -p --resume` restore plan. Otherwise a `-p` resume starts where a new `-p` run would, so pass `--permission-mode default` for a predictable Manual start. The one exception runs the other way: a `--bg` session keeps the mode across a supervisor restart. The flag is a per-launch statement of intent, and Claude Code refuses to remember it for you.

 

## How do I skip permissions?

 

Pick the narrowest option that still gets the job done. `--allowedTools` pre-approves named tools and command prefixes. `--permission-mode acceptEdits` covers file edits and basic filesystem commands. `dontAsk` denies everything that would prompt. That suits CI. `auto` replaces you with a classifier. `--dangerously-skip-permissions` removes almost every check. The docs reserve it for containers and VMs.

 

| Option | Runs without a prompt | The rest |
| --- | --- | --- |
| `--allowedTools "Bash(git diff *)" "Read"` | The listed tools and prefixes | Prompts; in a `-p` run with nobody to answer, denied unless a rule or hook resolves it |
| `--permission-mode acceptEdits` | Reads, edits, `mkdir`, `touch`, `mv`, `cp`, `rm` in the working directory | Prompts |
| `--permission-mode dontAsk` | Reads, the built-in read-only Bash command set, allow rules, hook-approved calls | Denied; the session never waits |
| `--permission-mode auto` | What the classifier passes | Blocked with a reason; prompts after repeated blocks |
| `--dangerously-skip-permissions` | Everything except the safeguards above (not an exhaustive list) | Each safeguard blocks or asks by its type; unresolved asks are denied in `-p` without a host, or handled by its configured host |
| `-p --permission-prompts none` | Per the mode | Unresolved requests denied, and Claude is told not to retry |

 

A `claude -p` cheat sheet, from the [headless page](https://code.claude.com/docs/en/headless): a print-mode run can start in auto mode from v2.1.285 when no mode is set and no feature flags apply, so pass `--permission-mode default` for a reproducible Manual start. A `-p` run with no permission host denies requests no rule or hook resolves, so a Manual job's first write is denied unless an allow rule or a `PermissionRequest` hook approves it. `Bash(git diff *)` needs the space before the `*`. Without it, `Bash(git diff*)` also matches `git diff-index`.

 

## The verdict

 

TESTED. `--dangerously-skip-permissions` takes the human out of the permission loop for one launch. Among the things that stay: deny rules, explicit ask rules, the `rm` circuit breaker, and a hook that denies or exits 2. Protected paths open up. The mode does not survive a resume. The allowlist becomes a log that decides nothing, secrets included. What can still hold under the flag is `permissions.deny` and hooks that deny or exit 2. Use it in a container where the agent can reach nothing you would miss. Use auto mode everywhere else. Never alias it.

 

Sources beyond the Claude Code pages linked above were first read on 15 September 2026. The Codex row was rechecked on 23 September 2026. On 11 October 2026 I rechecked all five agents against the pages linked in the comparison section. The original source list: [Codex configuration](https://learn.chatgpt.com/docs/config-file/config-reference), [Cursor CLI parameters](https://cursor.com/docs/cli/reference/parameters), Copilot CLI [programmatic](https://docs.github.com/en/copilot/reference/copilot-cli-reference/cli-programmatic-reference) and [command](https://docs.github.com/en/copilot/reference/copilot-cli-reference/cli-command-reference) references, [opencode permissions](https://opencode.ai/docs/permissions/), Gemini CLI [cheatsheet](https://geminicli.com/docs/cli/cli-reference/) and [configuration](https://geminicli.com/docs/reference/configuration/).

Put this into practice

[See the tool list](https://getagenttools.com/tools/)[Train your team](https://getagenttools.com/#training)