Is --dangerously-skip-permissions Safe? What the Flag Actually Turns Off

David Crowe · April 20, 2026 · Updated August 28, 2026 · 10 min read

claude-code anthropic governance security agentgovbench

Running Claude Code? See, control, and price every tool call it makes — allow/ask/deny policy, a per-session bill at API rates, and a full audit log, in one command:

curl -sf https://agenticcontrolplane.com/install.sh | bash

Full Claude Code guide → · see your first governed call → · free up to 5 agents

Correction (2026-07-28). An earlier version of this post claimed --dangerously-skip-permissions disables every PreToolUse and PostToolUse hook, so governance goes dark. That’s wrong, and we’re glad it is. We re-checked it against current Claude Code behavior and the docs: hooks fire regardless of permission mode, and a PreToolUse deny still blocks the call. The flag suppresses the interactive permission prompts — not the hook subsystem. So hook-based governance, ACP’s included, keeps running through it. The corrected picture is below; it’s better news than the original, and it changes the mitigations. We got it wrong, so we’re fixing it in place.

tl;dr

Is it safe? It is exactly as safe as the rules you wrote before you used it.

--dangerously-skip-permissions turns off the thing that interrupts you — the “Allow this tool call? (y/n)” prompt — by putting the session in bypassPermissions, which auto-allows everything through Claude Code’s permission system. Four things it does not turn off:

Deny rules, at every settings scope. Deny beats allow everywhere, and a managed (org-deployed) deny can’t be overridden even by a CLI flag.
Explicit ask rules, and MCP tools flagged as requiring interaction.
PreToolUse hooks. They fire in every permission mode — the hook even receives permission_mode: "bypassPermissions" as input, which it couldn’t if it never ran — and exit code 2 or permissionDecision: "deny" blocks the call unconditionally.
The rm -rf circuit breaker, which catches rm -rf / and rm -rf ~ even inside $(…), plus the refusal to run bypass mode as root.

So bypass mode isn’t “no controls.” It’s exactly your denies and your hooks, and nothing else — with every prompt that would have caught the rest removed. If your safety lived in the prompt, the flag is precisely what it says on the tin. If it lives in a deny rule or a hook, it survives. ACP’s ~/.acp/govern.mjs keeps deciding in a session started with the flag exactly as it does in one without it.

That’s the whole point of enforcing in a hook instead of in a prompt: the prompt is a request the user can wave through; the hook is a boundary that runs whether they wave or not.

The step-by-step version of “write those first” is how to run Claude Code in yolo mode safely. The same question across every other harness is Bypass Permissions Safely.

What the flag actually does

Two subsystems sit between the model and a tool call, and they’re separate:

The permission system — the interactive “do you want to proceed?” prompts. --dangerously-skip-permissions sets the session to bypassPermissions, which auto-allows every call through this system. No more prompts. This is the escape hatch Anthropic ships for power users.
The hook system — PreToolUse / PostToolUse commands wired in settings.json. These run on every tool call in every permission mode, including bypassPermissions — the hook even receives permission_mode: "bypassPermissions" as input, which it couldn’t if it never fired. A PreToolUse hook that emits a deny decision blocks the call regardless of the permission mode; staying silent lets it through, denying stops it.

So under the flag: the prompts are gone, the hooks are not. ACP’s hook still calls /govern/tool-use, still writes the audit line, and still blocks a policy deny or a safety-floor hit (rm -rf /, a force-push to main). If your governance is in the hook, the flag doesn’t move it.

The one honest caveat: because the permission prompts are gone, any control you’d built on a human eyeballing and approving each call is gone with them. If your safety lived in the prompt, --dangerously-skip-permissions is exactly what it sounds like. If it lives in the hook, you’re fine.

What genuinely can turn a hook off

The real bypass class isn’t this flag — it’s anything that removes the hook itself, which requires local control of the machine:

"disableAllHooks": true in settings.json — the explicit, documented switch that actually stops all hooks. (Enterprise admins can also pin hooks with allowManagedHooksOnly, blocking user/project overrides.)
Editing or deleting the hook entry in ~/.claude/settings.json, or uninstalling ACP.
Running a Claude Code build with no hook configured — a fresh install in a venv the config doesn’t reach.

The structural truth still holds, just at the right layer: a client-side hook can’t enforce against someone who removes the hook. That was always the real limit — not a permission flag, but local write access to the config. For a single developer that’s their own machine; for a fleet, it’s a fleet-management question.

If you need enforcement a local user can’t remove

Route the high-stakes tool calls through a layer that isn’t on the user’s machine. ACP fronts MCP servers at the network layer, and the gateway prices and governs model calls through the proxy — neither of which a client-side flag or a disableAllHooks edit can touch, because the enforcement isn’t client-side. That’s the honest answer for “this session touches production and I can’t trust the endpoint”: don’t rely on a hook the endpoint controls; put the boundary where the endpoint can’t reach it.

For everything else — a developer on their own machine who hasn’t gone out of their way to strip governance — the hook is the boundary, and this flag doesn’t lower it.

What AgentGovBench scores for this

The Claude Code scorecard has no category that “catches” --dangerously-skip-permissions, and now the reason is simpler than we first wrote: there’s nothing to catch. Hooks fire under the flag, so a hook-based governance layer behaves identically with or without it. The genuine “user opts out of governance” scenario is disableAllHooks / removing the hook — a local-control action, not a runtime one, which is why it’s a disclosure-compliance question (does your product tell users the client-removal path exists?) rather than a runtime test. We’re still scoping that client_bypass_disclosure category for v0.3; the trigger is just corrected.

What you should do today

Don’t treat --dangerously-skip-permissions as the hole. It isn’t one for rule- or hook-based enforcement. It removes prompts; keep your controls in the deny rules and the hook, not in the prompt.
Write the denies before you need them. A deny at any scope survives the flag, and a managed deny can’t be overridden by a CLI flag at all. The precedence, the scopes, and the documented fragility of argument-constrained Bash patterns are laid out on the Claude Code control-model page.
Know the real removal path. If audit completeness matters, the thing to watch is disableAllHooks and edits to settings.json — not this flag. At org scope, permissions.disableBypassPermissionsMode removes the mode and allowManagedHooksOnly pins the hooks.
For high-stakes workloads, add a layer the endpoint can’t remove. Route those calls through ACP’s network-layer MCP fronting / the model proxy, so enforcement doesn’t depend on a client-side hook staying in place.

The ordered checklist — denies, hook, sandbox, org switch, and the layer off the machine — is How to run Claude Code in YOLO mode safely.

Is --dangerously-skip-permissions safe to use?

It is exactly as safe as the rules you wrote before you used it. The flag puts the session in bypassPermissions, which auto-allows every call through Claude Code’s permission system — so every prompt that would have caught a mistake is gone. What it does not touch: deny rules at any settings scope, explicit ask rules, PreToolUse hook blocks, MCP tools flagged as requiring interaction, and an rm -rf circuit breaker that fires even inside command substitution. Bypass mode is not no controls; it is exactly your denies and your hooks, and nothing else.

Does --dangerously-skip-permissions disable Claude Code hooks?

No. Hooks fire in every permission mode, including bypassPermissions — the hook even receives permission_mode: bypassPermissions as part of its input, which it could not if it never ran. A PreToolUse hook that exits 2 or returns permissionDecision deny blocks the call regardless of mode. An earlier version of this post said otherwise; that was wrong and this page carries the correction.

What still blocks a command in bypassPermissions mode?

Four things. Deny rules at any scope (deny beats allow everywhere, and managed org-deployed denies cannot be overridden even by a CLI flag). Explicit ask rules and MCP tools flagged as requiring interaction. PreToolUse hook denies, which are unconditional. And Claude Code’s own circuit breaker for rm -rf / and rm -rf ~, which catches the command inside $(…) too, plus its refusal to run bypass mode as root. Everything else that was previously caught by a prompt now runs.

How do I stop someone running Claude Code with --dangerously-skip-permissions?

At org scope, permissions.disableBypassPermissionsMode in managed settings removes the mode entirely, and allowManagedHooksOnly pins hooks so a user or project cannot override them. The honest limit is that both live in files on the endpoint: a client-side control cannot enforce against someone with write access to the client’s config. For work where that matters, put the boundary somewhere the endpoint cannot reach — a proxy or gateway the calls must transit.

Anthropic’s trade is real — power users get to skip the prompts — but it’s a trade about prompts, not governance. We said otherwise; that was our error, and correcting it is the point of doing this in the open.

Receipts:

Claude Code hooks documentation — hook events, permission_mode input, PreToolUse deny, and disableAllHooks
Claude Code scorecard post
Claude Code integration page
The Tool Surface Index — the declared tools those hooks govern, by blast radius
Claude Code’s deny list can be bypassed — the client-side bypass classes and the enforcement layers that hold
The Claude Code control model, explained — the six modes, rule precedence, and the escape hatch stated precisely
What survives yolo mode — the same question asked of eleven harnesses, read from primary source

Share: Twitter LinkedIn