Permission Modes Deep Dive

Permission modes are the global setting that determines what Claude Code asks before doing. There are six of them, each appropriate for a different kind of work. Picking the right one — and knowing how to combine modes with permission rules — is the difference between a session that constantly interrupts you for trivia and one that runs ahead unchecked.

This article goes through each mode in detail, explains when to use it, and covers the patterns that combine modes and rules effectively.

The six modes at a glance

Mode-by-mode

default

The starting mode for new users and the right choice for sensitive work or unfamiliar tasks. Claude reads files freely but asks before any write, any bash command, any network call, any MCP tool call.

Use when: learning Claude Code, working in production code, doing anything where you want a beat to review each side-effect before it happens. The cost is interruptions; the benefit is total visibility.

Mental model: a careful new employee. Knows what they want to do, checks with you before doing it.

acceptEdits

The most popular mode for active development. File edits are applied without per-file approval. Bash, network, and MCP calls still prompt. The diff is still shown in the panel — you can still see what was changed — but the change is committed to disk before you confirm.

Use when: you are iterating on code or content where every prompt is friction and you trust Claude on file edits but not on running things or talking to the network.

Mental model: a colleague pair-programming with you. They write code freely; they still check before running tests, deploying, or sending anything externally.

plan

Pure investigation mode. Claude can read anything but cannot edit, write, or run anything that mutates state. Bash is restricted to read-only commands (ls, cat, git status) — anything mutating is blocked. Useful for exploring a problem before committing to a solution.

Use when: starting a new task and want to understand the codebase or document set first; auditing without changing anything; getting a recommendation without it turning into an implementation.

Mental model: a researcher. Pulls everything apart to understand it, puts it all back exactly how it was found.

auto

No permission prompts. Claude proceeds with whatever it judges sensible. A built-in classifier still checks each action against a risk model — clearly destructive operations may still be flagged — but the friction is removed. Designed for long-running sessions where you trust the direction and want Claude to keep going.

Use when: you have a clear, scoped task; you have committed to checkpoint or git for recovery; the work is reversible if Claude takes a wrong turn. Not appropriate for first-time tasks or production-critical changes.

Mental model: an experienced contractor. You hire them, brief them, leave them to it. You check the result.

dontAsk

Inverse of auto: instead of allowing everything not flagged as risky, dontAsk allows only what is explicitly pre-approved in the allow rules. Anything not on the list is denied silently — no prompt, no execution. The strictest mode short of plan.

Use when: running Claude Code in CI or any unattended context where you want guarantees that only specific commands execute. Set up the allow list in advance; expect the session to fail (rather than hang on a prompt) if it tries to do something outside the list.

Mental model: a kiosk. Performs only the operations on the menu. Anything else, the answer is no.

bypassPermissions

All permission checks disabled. Claude does whatever it decides to do. There are no prompts and no classifier blocks. Designed exclusively for use inside virtual machines, ephemeral containers, or sandboxed environments where the worst case is throwing the container away.

Use when: automated workflows in throwaway environments. Never on your primary workstation.

How to set the mode

Three ways:

1. Per-session, on the command line: claude --permission-mode acceptEdits
2. Persistent default for a workspace: in .claude/settings.json, set permissions.defaultMode
3. Mid-session: press Shift+Tab in the CLI to cycle through modes; in VS Code or Desktop, use the mode picker

{
  "permissions": {
    "defaultMode": "acceptEdits"
  }
}

Combining modes with permission rules

Permission mode is global per session — there is no per-tool mode. But allow, deny, and ask rules layered on top let you fine-tune:

• Mode default + allow list — pre-approve specific safe commands so they don't prompt; everything else still asks. Best for intermediate users who want most prompts but a handful of routine commands flowing through.
• Mode acceptEdits + deny list — let edits through, but explicitly block touching specific files (.env, secrets/) regardless of intent. Belt and braces.
• Mode auto + ask list — most things flow, but force a prompt for genuinely destructive operations (git push, npm publish) even when otherwise running unattended.
• Mode dontAsk + comprehensive allow list — the locked-down CI pattern. Define every command Claude is allowed to run. Anything else fails fast.

Evaluation order is always the same: deny first, then ask, then allow, then fall through to mode default. A deny rule wins even if there's also an allow rule for the same command.

Practical patterns

Pattern 1: solo developer, comfortable with Claude

{
  "permissions": {
    "defaultMode": "acceptEdits",
    "allow": [
      "Bash(git status:*)",
      "Bash(git diff:*)",
      "Bash(npm test:*)",
      "Bash(npm run lint:*)"
    ],
    "deny": [
      "Bash(rm -rf:*)",
      "Bash(git push --force:*)",
      "Edit(.env)"
    ],
    "ask": [
      "Bash(git push:*)",
      "Bash(npm publish:*)"
    ]
  }
}

Pattern 2: client work — one wrong move costs a relationship

{
  "permissions": {
    "defaultMode": "default",
    "allow": [
      "Bash(git status:*)",
      "Bash(git diff:*)"
    ],
    "deny": [
      "Bash(git push:*)",
      "Bash(curl:*)",
      "WebFetch(domain:*)"
    ]
  }
}

Pattern 3: locked-down CI run

{
  "permissions": {
    "defaultMode": "dontAsk",
    "allow": [
      "Bash(npm install:*)",
      "Bash(npm test:*)",
      "Bash(npm run build:*)",
      "Read(./**)",
      "Edit(./**)",
      "Write(./**)"
    ]
  }
}

Pattern 4: research / exploration session

Run with --permission-mode plan on the command line. No persistent change to settings.json. Investigate freely; switch modes when you're ready to act.

Reading the current mode

The current permission mode is shown in the status line at the bottom of the Claude Code panel. If your status line is customised and not showing it, you can also run /config to see the active configuration.

Common mistakes

• Defaulting to bypassPermissions for convenience. The mode exists for a specific scenario (disposable containers). Using it on your main machine is the equivalent of disabling your computer's seatbelt because the warning beep is annoying.
• Assuming auto = bypassPermissions. They are different. Auto still has a classifier that can block clearly dangerous actions. bypassPermissions disables every check.
• Forgetting that deny wins. Adding a permissive allow rule does not unblock something explicitly denied. Check the deny list when something is failing unexpectedly.
• Not setting any rules with dontAsk. Without an allow list, dontAsk blocks everything and the session is unusable. The mode is only useful with a comprehensive allow list set up first.
• Setting defaultMode in user settings and forgetting why a workspace behaves oddly. User settings apply everywhere. If a specific workspace needs a different mode, set it in that workspace's settings.local.json.