getting started

Claude Code Permission Modes Explained: auto, plan, dontAsk, bypassPermissions

Quick Answer

Claude Code has four permission modes: 'auto' (default — asks before risky actions), 'plan' (lists what it will do before acting), 'dontAsk' (skips confirmations for pre-approved tool patterns), and 'bypassPermissions' (no confirmations at all — use only in sandboxed CI). Mode is set via the --permission-mode flag or permissionMode in settings.json.

Claude Code's permission system answers one question: when should Claude act without asking you? Getting this right is the difference between a tool that constantly interrupts you and one that runs autonomously and safely. The four modes cover a range from 'always ask' to 'never ask'.

Auto mode is the default for interactive sessions. Claude will execute low-risk tool calls (reading files, running tests, grepping) without asking, but will pause before high-risk operations (deleting files, running arbitrary bash commands, making network requests). The risk assessment is heuristic — you can tune it by adding patterns to the allow/deny lists in settings.json.

Plan mode is the most careful mode. Before executing any tools at all, Claude produces a numbered plan of what it intends to do and asks for your approval. This is valuable when you're exploring an unfamiliar codebase and want to understand Claude's approach before it changes anything. It adds latency but gives maximum visibility.

dontAsk mode skips confirmation for all tool calls that match your allow list in settings.json. This is the right mode for well-defined tasks where you've already specified what Claude is allowed to do. A team running daily code-quality tasks (lint fixes, test runs, doc generation) with a carefully crafted allow list can run Claude in dontAsk mode safely.

bypassPermissions mode disables the confirmation system entirely — Claude will execute any tool call without pause. This should only be used in sandboxed environments (Docker containers with read-only mounts, ephemeral CI VMs) where the blast radius of a mistake is bounded by the infrastructure, not by Claude's judgment. Never use bypassPermissions on your local machine or against production infrastructure.

The --dangerously-skip-permissions flag (deprecated alias for bypassPermissions) appears in older docs. In Claude Code 1.x+ use `--permission-mode bypassPermissions` or set `"permissionMode": "bypassPermissions"` in settings.json for CI jobs. The settings.json value is overridden by the CLI flag if both are present.

Examples

Set permission mode via CLI flagbash
# Default interactive session (auto mode)
claude

# Plan mode — see the plan before any action
claude --permission-mode plan

# dontAsk — skip confirmations for allowed tools
claude --permission-mode dontAsk

# bypassPermissions — no confirmations (CI only)
claude --permission-mode bypassPermissions --print "Fix all lint errors"
settings.json: CI config with bypassPermissionsjson
{
  "permissionMode": "bypassPermissions",
  "permissions": {
    "allow": [
      "Bash(npm run lint:fix)",
      "Bash(npm test)",
      "Write",
      "Edit"
    ],
    "deny": [
      "Bash(rm:*)",
      "Bash(curl:*)",
      "Bash(wget:*)"
    ]
  }
}
GitHub Actions: safe bypassPermissions usagebash
# In .github/workflows/claude-lint.yml
# The GitHub Actions runner is an ephemeral VM — safe for bypassPermissions

steps:
  - uses: actions/checkout@v4
  - run: npm install -g @anthropic-ai/claude-code
  - run: |
      claude \
        --permission-mode bypassPermissions \
        --print "Fix all ESLint errors in src/. Do not change logic, only fix style."
    env:
      ANTHROPIC_API_KEY: ${{ secrets.ANTHROPIC_API_KEY }}

Tips

  • Use plan mode when onboarding Claude to a new codebase — seeing Claude's intended actions before it runs them teaches you what context it has (or lacks).
  • dontAsk + a tight allow list is safer than bypassPermissions — you get the speed without giving up tool-level access control.
  • Never commit settings.json with bypassPermissions for a local project — only use it in CI-specific settings files that are gitignored or only exist in CI environments.
  • The allow list supports glob-style wildcards: `Bash(git commit:*)` allows any git commit command while still blocking `Bash(git push:*)` if that's not in the allow list.
  • Team leads should set the project settings.json permission mode conservatively and let individual developers use personal ~/.claude/settings.json to relax restrictions for themselves.
  • If Claude is asking too many questions during a trusted automated task, move from auto to dontAsk mode rather than bypassPermissions — it's the right balance.

FAQ

What's the risk of using bypassPermissions on a local machine?+

With bypassPermissions, Claude will execute any bash command without asking — including `rm -rf`, database drops, or arbitrary network requests. On a local machine this means Claude could permanently delete files, corrupt databases, or exfiltrate data via curl. Reserve bypassPermissions for ephemeral environments with no access to production systems.

Can I set different permission modes for different tasks?+

Yes — pass --permission-mode as a CLI flag to override the settings.json value for a specific invocation. Your project settings.json can have 'auto' as the default, and your CI script can pass --permission-mode bypassPermissions for the automated job.

Does plan mode show all tool calls or just the first one?+

Plan mode shows Claude's complete intended plan before executing any step. Claude will list the sequence of tool calls it plans to make, you approve, and then it executes the full plan without further interruption (unless a tool call fails and replanning is needed).

What happens when Claude tries a denied tool call?+

If a tool call matches the deny list, Claude is told the action was blocked and includes the denial reason in its context. Claude will typically try to find an alternative approach or ask you how to proceed. It does not silently skip the action — it reports the block.

Related Guides