Benchmark series · Part 7 of 11

--dangerously-skip-permissions drops the prompts, not the hooks — your governance survives it

David Crowe · April 20, 2026 · Updated July 28, 2026 · 5 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 for individuals

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

--dangerously-skip-permissions turns off the thing that interrupts you — the “Allow this tool call? (y/n)” prompt — by auto-allowing everything through Claude Code’s permission system. It does not turn off hooks. Your PreToolUse and PostToolUse hooks still fire, your audit log still fills, and a hook that returns deny still stops the call. ACP’s ~/.acp/govern.mjs keeps governing a session started with the flag exactly as it governs 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.

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 a governance hole. It isn’t one for hook-based enforcement. It removes prompts; keep your controls in the hook, not the prompt.
Know the real removal path. If audit completeness matters, the thing to watch is disableAllHooks and edits to settings.json — not this flag. Manage the hook config the way you manage any other endpoint policy.
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.

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

Share: Twitter LinkedIn