What Claude Code’s --dangerously-skip-permissions Really Skips (and What It Doesn’t)

Almost every team that runs Claude Code in CI eventually reaches for --dangerously-skip-permissions. The approval prompts that make sense on a laptop are a hard stop in a non-interactive pipeline, so the flag gets added, the build goes green, and what exactly was skipped rarely gets asked again. The honest answer is narrower than the flag's name suggests: it skips the interactive confirmation prompts, and does not switch off the rest of the enforcement model.

That distinction matters because it changes how you reason about the blast radius. A developer running with the flag has not disabled deny rules or PreToolUse hooks; they have removed the human-in-the-loop step that used to sit in front of write and shell operations. If your only control was that prompt, you now have nothing. If you built enforcement at the hook layer, it still fires. We have walked through the broader version of this trade-off in securing AI coding agents and CLIs; this post zooms in on the single flag that gets the most reach and the least scrutiny.

What the flag actually changes

--dangerously-skip-permissions selects the bypassPermissions permission mode. Per Claude Code's permissions documentation, that mode "skips permission prompts, except those forced by explicit ask rules." Claude Code normally uses a tiered system: read-only tools run silently, while Bash commands and file modifications require approval the first time. Bypass mode removes the approval step for tools that would otherwise prompt, including writes to sensitive directories like .git, .claude, .vscode, and .idea.

Two safeguards survive even in bypass mode, and they are worth naming precisely. Explicit ask rules still force a prompt. And removals targeting the filesystem root or home directory - rm -rf / and rm -rf ~ - still prompt as a documented circuit breaker against model error. Everything else that used to ask, no longer asks. That is the entire behavioral change. It is meaningful on a shared or production-adjacent machine, but it is not the same as turning off Claude Code's enforcement layer - a common misreading.

What it does not skip: hooks and deny rules

The part teams miss is that the permission *prompt* and the permission *rules* are different things, and only the prompt is interactive. PreToolUse hooks and deny rules are not prompts - they are evaluation logic, and they run regardless of permission mode. Claude Code's hooks documentation is explicit: hooks fire for all events regardless of permission mode, and PreToolUse specifically runs in auto mode, in bypassPermissions mode, and in dontAsk mode. A PreToolUse hook still sees every tool call before it executes.

This is the lever that keeps working when the flag is set. A PreToolUse hook returns a structured decision on each call - allow, deny, ask, or defer to the normal flow - via the permissionDecision field, and a hook that exits with code 2 blocks the call outright. The permissions docs reinforce the ordering: hook decisions do not bypass permission rules, deny and ask rules are evaluated regardless of what a hook returns, and a blocking hook takes precedence over allow rules. The model cannot talk its way past any of this, because none of it is the model's decision.

The same allow-versus-deny asymmetry shows up across the agent ecosystem, and it is exactly where things go wrong when the wiring is subtly off. We documented one such case in the Claude Code GitHub Action bot-actor bypass, where the gap was not a skipped prompt but an identity assumption that let an action run with more authority than intended. The flag is not the only way to lose your guardrails.

Why bypass mode bites harder in CI than on a laptop

On a developer laptop, bypass mode trades safety for speed against a human who is watching the session and can interrupt it. In CI the human is gone, the credentials are usually broader (a CI runner often holds registry tokens, cloud roles, and push access), and the input the agent acts on is frequently attacker-reachable - a pull request title, an issue body, a dependency's README. Strip the prompt in that environment and a prompt-injection payload that reaches the agent runs with the runner's full authority and no one to say no.

That is not hypothetical. The comment-and-control multi-agent prompt injection research shows untrusted text steering an agent toward credential theft, and CVE-2025-59536, the Claude Code project-file RCE and token exfiltration shows a checked-in config file driving execution. In an interactive session the user is the last line of defense. With --dangerously-skip-permissions set in a pipeline, that line is gone unless a hook or a deny rule is standing where the prompt used to be.

A worked comparison

What to check before you trust the flag in a pipeline

If your CI runs Claude Code with the flag, the prompt is not protecting you, so the enforcement has to live somewhere that does not depend on a human. A practical checklist:

• Move the boundary into a PreToolUse hook. Add Bash to the allow list and register a hook that denies the specific commands and destinations you never want - pushes to protected branches, writes to credential paths, network egress to unapproved hosts. The hook runs in bypass mode; the prompt does not.
• Keep deny rules and managed settings in version control. Deny rules survive bypass mode and follow settings precedence, with managed settings overriding everything below them - including command-line flags. An admin can also set permissions.disableBypassPermissionsMode to "disable" to remove the flag's effect entirely on managed machines.
• Scope the runner's credentials to the task. The flag's danger scales with what the runner can reach. Short-lived, narrowly scoped tokens shrink the blast radius if a call does get through.
• Confirm hooks are actually loaded. A hook that is defined but not discovered is no control at all. Verify the settings file location the runner reads, and watch for allowManagedHooksOnly, which blocks user and project hooks when set.
• Log every decision, not just the denials. A skipped prompt leaves no trace of what was approved. You want a record of what the agent did and what enforcement returned, independent of the agent itself.

Where hook-based enforcement still leaves a gap

PreToolUse hooks are powerful, and they are also per-endpoint, per-config, and self-reported. The hook lives in a settings file on one machine; whether it is present, current, and matching the right tools is a property of that machine, not something a security team can see from outside. A laptop with edited local settings, a runner image that shipped without the hook, a project that overrode the matcher - each is a hole that looks identical to a healthy endpoint from any vantage point that only watches the network or the OS.

This is the same structural blind spot that makes stdio MCP servers an RCE surface by design: the risk lives in the AI artifact and its local configuration, where EDR, DLP, and network tooling were never built to look. The flag does not create this gap, but it makes the consequences of an unenforced endpoint more immediate, because the prompt that used to paper over a missing hook is no longer there.

This is the layer Anomity is built to make visible and governable. It inventories the AI artifacts on every managed endpoint - agents, MCP servers, extensions, skills, plugins, hooks, secrets, and CLIs - so you can see which machines actually have hook-based enforcement wired up and which are running a coding agent with the flag set and nothing behind it. On agents that expose a hook like Claude Code's PreToolUse, Anomity returns allow, deny, or log on each tool call before it runs, and keeps a queryable 90-day audit trail of what was decided - metadata only, with secret redaction on the endpoint. None of that replaces your network, EDR, or DLP controls; it covers the artifact layer they cannot inventory. If you are deciding whether to trust --dangerously-skip-permissions across a fleet, start by seeing the full agent and MCP inventory you are actually governing, then come talk to us about early access.