--dangerously-skip-permissionsWhen to Use It, When to Avoid It

Claude Code ships with training wheels. By default, it asks permission before every file edit, every shell command, every action that could modify your codebase. This made sense back in the Claude 3.5 days when models were unpredictable—sometimes brilliant, sometimes confidently wrong. You needed the checkpoints.

But we're in a different era now. Claude 4 and Opus-class models are high-trust. They understand codebases, respect conventions, and rarely hallucinate destructive commands. The permission prompts that once saved you from chaos now mostly interrupt flow state.

The --dangerously-skip-permissions flag removes those training wheels entirely. It tells Claude Code to execute without asking. The name is dramatic—Anthropic erred on the side of caution—but for experienced developers working with modern models, it's often the right choice.

This guide covers what the flag actually does, when you should use it, and the granular permission system in settings.json for those who want something in between.

What --dangerously-skip-permissions Actually Does

When you launch Claude Code with --dangerously-skip-permissions, you're activating what Anthropic calls "Bypass Permissions Mode." Every action Claude proposes—file writes, shell commands, test executions, even web fetches—proceeds immediately without confirmation.

Think of it like running sudo on every command. Powerful, but one wrong move can cascade.

The flag is typically used in two scenarios: CI/CD pipelines where no human is present to click "approve," and trusted local development sessions where constant permission prompts break flow state.

Here's the basic invocation:

claude --dangerously-skip-permissions -p "Refactor the auth module to use JWT tokens"

The -p flag passes a prompt directly. Combined with --dangerously-skip-permissions, Claude executes the task from start to finish without stopping.

The Permission System You Should Probably Use Instead

Before reaching for the nuclear option, consider Claude Code's granular permission configuration. The settings.json file in your .claude directory lets you whitelist specific commands while blocking dangerous ones.

A typical configuration looks like this:

{
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test:*)",
      "Bash(git status)",
      "Read(*)",
      "Write(./src/**)"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(curl:*)",
      "Read(./.env)",
      "Read(./secrets/**)"
    ],
    "ask": [
      "Bash(git push:*)",
      "Write(./production/**)"
    ]
  }
}

This configuration achieves something the blanket flag cannot: it grants Claude autonomy for safe operations while maintaining guardrails around destructive commands. The allow list auto-approves. The deny list blocks outright. The ask list forces a confirmation—even in auto-accept mode.

Pattern matching with wildcards (*) lets you express policies like "any test command is fine" without listing every variant.

Interactive Permission Modes

For interactive sessions, Claude Code offers a middle ground between constant prompts and full bypass. Press Shift+Tab to cycle through four modes:

Default Mode prompts on first use of each tool type. Approve file editing once, and subsequent edits proceed automatically for that session.

Accept Edits Mode auto-approves all file modifications but still prompts for shell commands. Useful when you're focused on code changes rather than system operations.

Plan Mode lets Claude analyze and propose changes without executing anything. Good for reviewing what the assistant wants to do before committing.

Bypass Permissions Mode matches the CLI flag—full autonomy, no prompts. The UI clearly indicates when this mode is active.

The current mode displays in the Claude Code interface. Most developers find Accept Edits Mode hits the right balance: fast iteration on code, human oversight on commands.

When --dangerously-skip-permissions Makes Sense

The flag's name is scarier than the reality. Here's when it makes sense:

CI/CD Pipelines: Automated systems can't click approve buttons. If you're running Claude Code in GitHub Actions or similar environments, you need non-interactive execution.

Scripted Batch Operations: Processing hundreds of files with a known-safe transformation doesn't require human confirmation at each step.

Sandboxed Environments: If Claude Code runs in an isolated container with nothing to destroy, the risk calculus changes.

Trusted Refactoring Sessions: When you have a clear implementation plan, version control as a safety net, and full understanding of what Claude will change, constant prompts just slow you down.

The common thread: you've already made the security decision elsewhere. The flag isn't granting trust—it's acknowledging trust you've already established.

Security Considerations Worth Knowing

Modern Opus-class models rarely generate destructive commands unprompted. But they're still not perfect at everything:

Context Pollution: In long sessions with many files, models can get confused about which file they're editing or mix up similar variable names. This isn't dangerous—just annoying. The fix is starting fresh sessions for complex refactors.

Speed vs Accuracy Tradeoffs: When working fast, models occasionally make assumptions rather than asking clarifying questions. With permissions bypassed, those assumptions execute immediately.

Credential Paths: Worth adding `.env` and secrets directories to your `deny` list, not because Claude will steal them, but because it might accidentally log them while debugging.

Network Requests: Claude can make HTTP requests if not restricted. Usually this is fine (fetching docs, testing endpoints), but worth knowing.

The realistic mitigation: use git. If something goes wrong, git checkout . fixes it. The permission system exists as a second layer, not the only layer.

A Better Mental Model

Think of Claude Code's permission system as defense in depth:

Layer 1: Default prompts catch everything unusual.

Layer 2: `settings.json` whitelists known-safe operations and blocks known-dangerous ones.

Layer 3: Interactive mode selection (`Shift+Tab`) adjusts trust level per session.

Layer 4: `--dangerously-skip-permissions` removes all software guardrails, shifting responsibility entirely to you.

Most developers should exhaust layers 1-3 before reaching layer 4. The configuration file approach gives you 90% of the workflow benefit with 10% of the risk.

Practical Setup for Teams

If your team uses Claude Code, establish conventions around permissions:

Create a shared .claude/settings.json in your repository with sane defaults. Whitelist your standard toolchain (linters, formatters, test runners). Blacklist anything that touches production infrastructure.

Document when --dangerously-skip-permissions is acceptable. CI pipelines running in ephemeral containers are reasonable. Developer laptops with access to production credentials are not.

Consider environment-specific configs. Your local development settings might be more permissive than what runs in CI.

The Bottom Line

Anthropic named the flag --dangerously-skip-permissions back when that caution made sense. Claude 3.5 models were brilliant but unpredictable. You wanted checkpoints.

Today's Opus-class models are different. They're high-trust for code work—they understand your codebase, follow conventions, and rarely suggest destructive actions. The remaining failure modes are mostly about context pollution in long sessions and occasional speed-over-accuracy tradeoffs.

For most experienced developers, the full bypass is reasonable. Git provides the safety net. The permission system is there if you want belt-and-suspenders, not because modern models require it.

Start wherever feels right. Some developers go straight to bypass mode. Others prefer the settings.json approach to whitelist their toolchain. Both work. The goal is uninterrupted flow state, not maximum caution.

{
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test:*)",
      "Bash(npm run build)",
      "Bash(git status)",
      "Bash(git diff:*)",
      "Read(*)",
      "Write(./src/**)",
      "Write(./tests/**)"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(curl:*)",
      "Bash(wget:*)",
      "Read(./.env*)",
      "Read(./secrets/**)",
      "Write(./.env*)"
    ],
    "ask": [
      "Bash(git push:*)",
      "Bash(git commit:*)",
      "Bash(npm publish:*)",
      "Write(./package.json)"
    ]
  }
}