# Is --dangerously-skip-permissions Safe? What the Flag Actually Turns Off The flag drops Claude Code's permission prompts — not your deny rules, not your PreToolUse hooks, not the rm -rf circuit breaker. Here is precisely what still holds under bypassPermissions, what genuinely turns the controls off, and what to write before you use it. > **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](/blog/run-claude-code-yolo-safely). The same question across every other harness is [Bypass Permissions Safely](/blog/bypass-permissions-safely).* ## What the flag actually does Two subsystems sit between the model and a tool call, and they're separate: 1. **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. 2. **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](/blog/full-scorecard-seven-frameworks-48-scenarios) 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 1. **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. 2. **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](/controls/claude-code). 3. **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. 4. **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](/blog/run-claude-code-yolo-safely). 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](https://code.claude.com/docs/en/hooks) — hook events, `permission_mode` input, PreToolUse `deny`, and `disableAllHooks` - [Claude Code scorecard post](/blog/full-scorecard-seven-frameworks-48-scenarios) - [Claude Code integration page](/integrations/claude-code) - [The Tool Surface Index](/tool-surfaces) — the declared tools those hooks govern, by blast radius - [Claude Code's deny list can be bypassed](/blog/claude-code-deny-list-bypass) — the client-side bypass classes and the enforcement layers that hold - [The Claude Code control model, explained](/controls/claude-code) — the six modes, rule precedence, and the escape hatch stated precisely - [What survives yolo mode](/blog/what-survives-yolo-mode) — the same question asked of eleven harnesses, read from primary source