Claude Code --dangerously-skip-permissions: Complete Guide to Permission Modes, Safe Automation, and CI/CD Setup

What --dangerously-skip-permissions Actually Does

When you launch Claude Code with --dangerously-skip-permissions, you activate what Anthropic calls Bypass Permissions Mode. Every action Claude proposes proceeds immediately without confirmation:

• File edits and writes
• Shell command execution
• MCP tool calls
• Web fetch requests
• Subagent spawning

# One-shot task with full bypass
claude --dangerously-skip-permissions -p "Refactor the auth module to use JWT tokens"

# Named session with bypass
claude --dangerously-skip-permissions --resume refactor-sprint "Continue refactoring"

# Combine with output format for scripting
claude --dangerously-skip-permissions -p "Fix all lint errors" --output-format json

The -p flag passes a prompt directly and runs in headless mode. Combined with --dangerously-skip-permissions, Claude executes the task from start to finish without stopping. No human in the loop.

The 5 Claude Code Permission Modes

--dangerously-skip-permissions is one of 5 permission modes. Most developers never need it because the other 4 cover the common cases. Press Shift+Tab to cycle through the first three interactively.

Default Mode

Prompts on first use of each tool type. Approve file editing once and subsequent edits proceed automatically for that session. Shell commands still prompt individually. This is what you get out of the box.

Accept Edits Mode

Auto-approves all file modifications but still prompts for shell commands. The sweet spot for most developers. You get fast iteration on code changes with human oversight on commands that could have side effects. Activate with Shift+Tab.

Plan Mode

Claude can read and analyze but cannot modify files or execute commands. Use this when you want Claude to propose changes without executing them, or to review a codebase before committing to an approach.

Don't Ask Mode

Auto-denies all tool usage unless the tool is explicitly pre-approved via /permissions or your permissions.allow rules. Claude will not prompt you for confirmation. If a tool is not in the allowlist, it is silently denied. This mode is useful for locked-down environments where you want zero unexpected actions.

Bypass Permissions Mode

Equivalent to --dangerously-skip-permissions. All tools execute without prompting. Set it interactively with Shift+Tab or in your config with "defaultMode": "bypassPermissions". Only use this in isolated environments.

settings.json: Granular Permission Control

Before reaching for --dangerously-skip-permissions, configure the permission system that gives you fine-grained control. The .claude/settings.json file in your project root lets you allowlist specific tools while blocking dangerous ones.

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

Three categories of rules:

• allow auto-approves the tool. No prompt, no delay.
• deny blocks the tool entirely. Claude cannot use it even if asked.
• ask forces a confirmation prompt, even in Accept Edits mode.

Rules evaluate in order: deny > ask > allow. The first matching rule wins. A deny rule always takes precedence, which means you can use a broad allow rule and carve out exceptions with deny.

Permission Rule Syntax

Rules follow the format Tool or Tool(specifier). The specifier supports glob patterns with *.

Bash Rules

Wildcards can appear at any position in the command:

"Bash(npm run build)"        // Exact match: only "npm run build"
"Bash(npm run *)"            // Prefix match: "npm run test", "npm run lint", etc.
"Bash(* --version)"          // Suffix match: any command ending with --version
"Bash(git * main)"           // Middle match: "git checkout main", "git merge main"
"Bash(*)"                    // Matches all Bash commands (same as just "Bash")

Read and Edit Rules

Follow the gitignore specification with four path prefix types:

Note: * matches files in a single directory. ** matches recursively across directories. To allow all file access, use the tool name without parentheses: Read, Edit, or Write.

Other Tool Rules

"WebFetch(domain:example.com)"         // Restrict web fetches by domain
"mcp__puppeteer"                       // All tools from the puppeteer MCP server
"mcp__puppeteer__puppeteer_navigate"   // Specific MCP tool
"Agent(Explore)"                       // The Explore subagent

Per-Project and Per-User Permission Configuration

Settings follow a hierarchy. More specific settings override less specific ones:

Array settings (like permission rules) merge across scopes rather than replace. If a permission is allowed in user settings but denied in project settings, the project deny wins. If a tool is denied at any level, no other level can allow it.

{
  "permissions": {
    "allow": [
      "Bash(npm run *)",
      "Bash(git diff *)",
      "Read",
      "Edit(/src/**)"
    ],
    "deny": [
      "Bash(rm -rf *)",
      "Read(./.env*)"
    ]
  }
}

{
  "permissions": {
    "allow": [
      "Bash(docker compose *)",
      "Edit(/infrastructure/**)"
    ],
    "defaultMode": "acceptEdits"
  }
}

Use the /permissions command inside Claude Code to view all active rules and which settings file they come from. Use /config to edit settings interactively.

Common Permission Prompts and How to Auto-Allow Them

These are the prompts developers hit most often. Here is how to auto-approve each one without reaching for --dangerously-skip-permissions:

You can also add rules interactively. When Claude prompts you for permission, selecting "Always allow" adds the rule to your settings file. Or use the /permissions command to add rules manually during a session.

# Allow specific tools for this session only
claude --allowedTools "Bash(npm run *)" "Bash(git *)" "Read" "Edit"

# Deny specific tools for this session
claude --disallowedTools "Bash(curl *)" "Bash(wget *)"

# Combine both
claude --allowedTools "Read" "Edit" --disallowedTools "Bash(rm *)" "Bash(sudo *)"

When --dangerously-skip-permissions Makes Sense

The flag is not as dangerous as the name implies, if you have the right safety nets in place. Four scenarios where it is the right choice:

The common thread: you have already made the security decision elsewhere. The flag is not granting trust. It is acknowledging trust you have already established through isolation, version control, or both.

When NOT to Use --dangerously-skip-permissions

A study from eesel AI found that 32% of developers using --dangerously-skip-permissions encountered at least one unintended file modification. 9% reported data loss. The solution is not to avoid the flag entirely, but to pair it with proper isolation.

Docker Setup for Safe Autonomous Mode

The recommended way to use --dangerously-skip-permissions safely is inside a container. Anthropic provides a reference devcontainer setup with built-in firewall rules.

FROM node:20-slim

# Install Claude Code globally
RUN npm install -g @anthropic-ai/claude-code

# Install essential dev tools
RUN apt-get update && apt-get install -y \
    git \
    iptables \
    && rm -rf /var/lib/apt/lists/*

# Copy firewall initialization script
COPY init-firewall.sh /usr/local/bin/init-firewall.sh
RUN chmod +x /usr/local/bin/init-firewall.sh

# Create non-root user
RUN useradd -m -s /bin/bash developer
USER developer
WORKDIR /home/developer/project

ENTRYPOINT ["/usr/local/bin/init-firewall.sh"]

#!/bin/bash
# Allow DNS
iptables -A OUTPUT -p udp --dport 53 -j ACCEPT
iptables -A OUTPUT -p tcp --dport 53 -j ACCEPT

# Allow connections to Anthropic API
iptables -A OUTPUT -d api.anthropic.com -j ACCEPT

# Allow npm registry for package installs
iptables -A OUTPUT -d registry.npmjs.org -j ACCEPT

# Allow GitHub
iptables -A OUTPUT -d github.com -j ACCEPT

# Block everything else
iptables -A OUTPUT -j DROP

# Run Claude Code
exec claude --dangerously-skip-permissions "$@"

# Build
docker build -t claude-sandbox .

# Run with your code mounted read-write
docker run -it \
  -e ANTHROPIC_API_KEY=$ANTHROPIC_API_KEY \
  -v $(pwd):/home/developer/project \
  claude-sandbox -p "Fix all TypeScript errors"

# Maximum isolation: read-only source, no network
docker run -it \
  -e ANTHROPIC_API_KEY=$ANTHROPIC_API_KEY \
  -v $(pwd):/home/developer/project:ro \
  -v /tmp/claude-output:/home/developer/output \
  --network=none \
  claude-sandbox -p "Analyze this codebase for security issues"

The official devcontainer from github.com/anthropics/claude-code/.devcontainer includes a more complete firewall with precise domain whitelisting, VS Code integration, and session persistence. Use it as a starting point.

GitHub Actions / CI/CD Setup

Anthropic provides an official GitHub Action for integrating Claude Code into your CI/CD workflow. Two approaches: the action (for PR-based workflows) and raw headless mode (for arbitrary automation).

Official GitHub Action

name: Claude Code
on:
  issue_comment:
    types: [created]
  pull_request_review_comment:
    types: [created]

permissions:
  contents: write
  pull-requests: write
  issues: write

jobs:
  claude:
    if: contains(github.event.comment.body, '@claude')
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - uses: anthropics/claude-code-action@v1
        with:
          anthropic_api_key: ${{ secrets.ANTHROPIC_API_KEY }}
          claude_args: "--max-turns 10"

Headless Mode in CI

name: Claude Lint Fix
on:
  push:
    branches: [main]

jobs:
  fix:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4

      - uses: actions/setup-node@v4
        with:
          node-version: '22'

      - run: npm install -g @anthropic-ai/claude-code

      - name: Fix lint errors
        env:
          ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}
        run: |
          claude --dangerously-skip-permissions \
            -p "Fix all ESLint errors in src/" \
            --max-turns 5 \
            --allowedTools "Read" "Edit" "Bash(npm run lint)"

      - name: Commit fixes
        run: |
          git config user.name "Claude Code"
          git config user.email "claude@example.com"
          git add -A
          git diff --staged --quiet || git commit -m "fix: auto-fix lint errors"
          git push

Key flags for CI:

• --max-turns caps execution to prevent runaway costs
• --allowedTools restricts which tools Claude can use in the pipeline
• --output-format json or stream-json for programmatic output parsing
• -p runs in headless mode (no interactive interface)

Claude Code Headless Mode

Headless mode runs Claude Code without an interactive interface. It is the foundation for all CI/CD and scripting use cases.

# Simple prompt, text output to stdout
claude -p "Generate a .gitignore for Node.js"

# Pipe stdin as context
cat src/utils.ts | claude -p "Find potential bugs in this file"

# JSON output with metadata
claude -p "List all TODO comments" --output-format json

# Streaming JSON Lines (NDJSON) for real-time processing
claude -p "Refactor this module" --output-format stream-json

# Multi-turn: maintain context across calls
claude -p "Analyze the codebase" --session-id my-session --output-format json
claude -p "Now fix the issues you found" --resume my-session

Three output formats: text (default, raw response on stdout), json (structured object with metadata), and stream-json (tokens as JSON Lines for real-time processing).

Managed Settings for Teams and Organizations

Organizations that need centralized control can deploy managed settings that no user or project can override. This includes the ability to disable --dangerously-skip-permissions entirely.

// macOS: /Library/Application Support/ClaudeCode/managed-settings.json
// Linux: /etc/claude-code/managed-settings.json
{
  "permissions": {
    "deny": [
      "Bash(rm -rf *)",
      "Bash(sudo *)",
      "Read(//etc/**)"
    ]
  },
  "disableBypassPermissionsMode": "disable",
  "allowManagedPermissionRulesOnly": true
}

Key managed-only settings:

• disableBypassPermissionsMode: set to "disable" to block --dangerously-skip-permissions and bypass mode entirely
• allowManagedPermissionRulesOnly: prevents user and project settings from defining their own permission rules
• allowManagedHooksOnly: blocks user/project hooks, only managed hooks run
• allowManagedMcpServersOnly: restricts MCP servers to the managed allowlist

Managed settings cannot be overridden by CLI arguments, project settings, or user settings. They are the final word.

Frequently Asked Questions