Claude Code --dangerously-skip-permissions: The Safe Alternative

You've seen the flag. Maybe you typed it yourself after the fifth permission prompt interrupted your flow in ten minutes. Maybe you found it in a tutorial or a CI/CD config someone shared on GitHub. Either way, you're here because you want to know: is there a way to get the speed of --dangerously-skip-permissions without the part where Claude has unrestricted access to your entire machine?

Yes. Policy-as-code. And it takes about five minutes to set up.

But first, let's be honest about what the flag does, why developers use it, and what actually goes wrong when they do.

What --dangerously-skip-permissions Actually Does

Claude Code has a built-in permission system. Every time the agent wants to do something potentially risky, it pauses and asks you to confirm. The --dangerously-skip-permissions flag turns all of that off. Every prompt. Every check. Gone.

Specifically, the flag bypasses permission prompts for:

• File reads and writes — Claude can read any file on your system and write to any path, including outside your project directory. Your .ssh keys, your .env files, your shell configs. All accessible without a prompt.
• Bash command execution — Every shell command runs without confirmation. rm -rf, curl to arbitrary endpoints, chmod, package installs, process kills. Whatever Claude decides to run, it runs.
• MCP tool calls — If you have MCP servers connected, Claude can call any tool on any server without asking. Database queries, API calls, file operations through external tooling — all auto-approved.
• Browser actions — Web fetches, page interactions, form submissions. No confirmation required.
• Notebook editing — Jupyter notebook cells execute without review.

In short: the flag converts Claude Code from a supervised tool into an unsupervised agent with your full user permissions. No selective bypass. All or nothing.

Why Developers Use It

The honest answer: because the alternative is slow. A refactoring session can hit 30-50 permission prompts. Each one breaks your flow for a decision you already made when you wrote the prompt.

Developers reach for the flag for legitimate reasons:

• Iterative speed. Permission prompts turn a 30-second build-test-fix cycle into a 3-minute one. Over an afternoon, that's hours lost.
• CI/CD and automation. There's no human at the terminal in a CI pipeline. Non-interactive execution requires either the flag or an alternative.
• Batch operations. Renaming 200 files or updating import paths across a monorepo. Per-action approval on low-risk, high-volume tasks is pure overhead.
• Context switching costs. Every prompt pulls you out of whatever architectural thinking you were holding in your head.

These are real problems. The flag solves them. The issue is what it trades away.

What Goes Wrong

The flag is called --dangerously-skip-permissions for a reason. Anthropic named it that on purpose — as a warning built into the syntax. Here's what happens when that warning gets ignored.

Scenario 1: The Recursive Delete

A developer is using Claude Code with --dangerously-skip-permissions to clean up a project directory. The prompt is something like "remove all the build artifacts and temporary files." Claude interprets "temporary files" more broadly than intended and runs rm -rf on directories that contain source files matching patterns it associates with generated code. No prompt appears to confirm the deletion scope. The files are gone. If there's no recent git commit, some of that work is unrecoverable.

Variations of this show up in developer forums and GitHub issues regularly. The common thread: a vague instruction, an agent that interpreted it broadly, and no checkpoint to catch the mismatch. [NEEDS SOURCE: specific public incident report or GitHub issue documenting rm -rf data loss with --dangerously-skip-permissions]

Scenario 2: Credential Exposure

Claude is setting up a deployment pipeline. With permissions skipped, it reads .env to understand the project config — reasonable — then includes those values in a generated file that gets committed to version control. Or it passes API keys as curl arguments that land in shell history. Or it writes a debug log containing database connection strings.

Claude isn't being malicious. But without a permission prompt, there's no checkpoint where you'd see "Claude wants to read .env" and ask "why does it need that?" The risk compounds with MCP servers: if Claude has database access via MCP, it can query any table and include that data in files it writes — all auto-approved. [NEEDS SOURCE: documented credential exposure incident via skipped permissions]

Scenario 3: The Runaway Loop

Claude hits an error. Tries to fix it. The fix creates a new error. With permissions enabled, you'd notice the loop after two or three retries. With the flag set, Claude burns through dozens of iterations — rewriting files, re-running failing commands, hammering external services — before you realize anything is wrong.

These scenarios share a pattern: the flag removes the human checkpoint at exactly the moment when one would have caught the problem.

The Policy-as-Code Alternative

Here's the thing: the permission prompt model and the skip-permissions flag represent two extremes. Approve everything manually, or approve everything automatically. Neither is what most developers actually want.

What you want is: approve the stuff that's obviously fine automatically, and block the stuff that's obviously dangerous automatically, and only interrupt me for the stuff in between.

That's policy-as-code. You define rules — in plain, auditable YAML — that specify what the agent is allowed to do. Everything matching an allow rule executes without a prompt. Everything matching a block rule gets stopped before execution. The ambiguous middle ground can be configured to notify you or block, depending on your risk tolerance.

Shoofly Advanced implements this with two components:

The daemon — a background sidecar process that maintains state. It tracks tool call frequency, detects repeated patterns, and enforces rate-based rules (like "no more than 20 tool calls in 30 seconds"). It runs locally on your machine. No data is sent externally. Ever.

The hook — a plugin that intercepts every tool call before it executes. Before Claude writes a file, runs a command, or calls an MCP tool, the hook evaluates the action against your policy rules. If the action matches a block rule, it exits with code 1 and the action never executes. If it matches a notify rule, it logs the event and lets it proceed. This happens in milliseconds — the developer experience is the same as --dangerously-skip-permissions. No prompts, no waiting. But with boundaries.

The key insight: policy enforcement is non-interactive, just like skip-permissions. No human bottleneck. The rules evaluate programmatically. You get the speed of the flag with explicit, version-controlled guardrails that you wrote and can audit anytime. The rules are YAML — open and auditable by design.

What Shoofly Catches That the Flag Bypasses

Shoofly Advanced ships with 20 rules across 5 threat categories. Here's what they cover and how they map to the permissions that --dangerously-skip-permissions skips:

Prompt Injection (PI) — 8 rules. When Claude reads files or fetches web content, that content can contain instructions designed to hijack the agent's behavior. With the flag set, Claude acts on injected instructions without any checkpoint. Shoofly scans tool outputs and arguments for injection patterns — including base64-encoded payloads — and blocks known jailbreak patterns before they reach the agent's context. (See: Prompt Injection Blocking: Pre-Execution Security)

Tool Response Injection (TRI) — 2 rules. MCP servers and external tools can return payloads with hidden instructions embedded in HTML comments or unexpected JSON keys. The flag lets these flow straight through. Shoofly detects and blocks instruction content hidden in tool responses.

Out-of-Scope Write (OSW) — 3 rules. This is the big one for --dangerously-skip-permissions users. Shoofly blocks writes to sensitive paths: /etc/, /usr/bin/, ~/.ssh/, ~/.aws/, shell config files, LaunchAgents, credential files (.key, .pem, .env). With the flag set, Claude can write anywhere your user account can write. With Shoofly, writes outside your project scope are blocked at the hook level, before the file operation executes.

Runaway Loop (RL) — 4 rules. The daemon tracks call frequency and detects patterns: same tool called 5+ times in 60 seconds, more than 20 total calls in 30 seconds, same file read-write cycle repeated 3+ times, same URL fetched 10+ times in a minute. When Claude enters a retry loop — the scenario where the flag is most dangerous — Shoofly kills the loop before it burns through your context window and your token budget.

Data Exfiltration (DE) — 4 rules. Credential patterns (API keys, private keys, AWS access keys) in outbound HTTP bodies. Sensitive file content piped to curl or wget. Credential data in messaging tool calls. Sensitive file reads followed immediately by network requests. These are the scenarios where --dangerously-skip-permissions turns a confused agent into a data leak. Shoofly catches the exfiltration chain at the tool call level.

Here's the comparison in plain terms:

The last two rows matter. Shoofly doesn't slow down legitimate work. It only intervenes on actions that match threat patterns. Everything else flows through at full speed.

For a deeper look at how pre-execution interception fits into a broader Claude Code security strategy, see our Securing Claude Code: Best Practices guide and the Claude Code Security overview.

Setup Guide

Switching from --dangerously-skip-permissions to Shoofly Advanced takes about five minutes.

Step 1: Install Shoofly Advanced.

curl -fsSL https://shoofly.dev/install-advanced.sh | bash

Everything installs to ~/.openclaw/ — no system-level changes, no sudo required.

Step 2: Review the default policy.

The policy file lives at ~/.openclaw/policy/threats.yaml. Open it. Read it. Every rule has an id, description, severity, and patterns block showing exactly what it matches. HIGH and MEDIUM severity rules block. LOW severity rules notify only.

- id: OSW-001
  name: sensitive_path_write
  category: out_of_scope_write
  severity: HIGH
  description: "Write operation targeting sensitive system or credential paths"
  patterns:
    - type: path_match
      value: ["/etc/", "/usr/bin/", "~/.ssh/", "~/.aws/", "~/.bashrc"]
      context: [tool_args]
  action_advanced: block

If a rule doesn't fit your workflow, you can adjust the severity or modify the patterns. The rules are yours to own.

Step 3: Remove the flag.

In your Claude Code launch command, your alias, or your CI config, replace:

claude --dangerously-skip-permissions

with:

claude

That's it. The hook intercepts tool calls automatically once installed. No flag needed. Claude Code runs at full speed, and the policy rules enforce your boundaries in the background.

Step 4: Check the logs.

After your first session, check what Shoofly caught: cat ~/.openclaw/logs/blocked.log. Every intercepted action shows which rule matched and what it would have done. This is your audit trail and your feedback loop for tuning the policy.

Step 5 (optional): Customize. Need Claude to write to specific paths, or trust certain MCP servers? Add allow rules in the same YAML format. Fork the policy, version-control it, share it with your team.

The --dangerously-skip-permissions flag exists because Claude Code's default permission model creates real friction for real workflows. That friction is a problem worth solving. But solving it by removing all guardrails is like fixing a slow door by removing the door.

Policy-as-code keeps the door. It just makes it fast — fast enough that you don't notice it's there until it stops something that would have ruined your afternoon.

Stop choosing between fast and safe. Shoofly Advanced gives you both. Pre-execution interception, 20 deterministic policy rules, 100% local enforcement. $5/mo. No data sent anywhere. Just rules you can read, running on your machine.