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

--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 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 flag hides that skill from the model, the PreToolUse hook reads every command before it runs, and permission modes decide who answers the prompt in between. In a 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 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 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 can change ask, deny and unmanaged-hook outcomes. The list is not exhaustive; the modes page keeps the current set.

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, 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 counts only ~/.claude/settings.json, --settings or managed settings:

{
  "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 declaring permissionMode: bypassPermissions keeps the parent's mode unless the parent is already in bypass, per the subagents page, 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). 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.

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.

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.

How do I skip permissions in Cursor CLI?

Pass -f or --force. The parameters page reads: "Force allow commands unless explicitly denied". --yolo is listed as "Alias for --force". Explicit denies still apply under --force. The permissions page 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 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. 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 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 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. 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 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 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 and record which tools execute outside that boundary.

Why it does not survive --resume

Per the sessions page, 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 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.

A claude -p cheat sheet, from the headless page: 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, Cursor CLI parameters, Copilot CLI programmatic and command references, opencode permissions, Gemini CLI cheatsheet and configuration.