Skip to main content

Permissions & Permission Modes

Intermediate
What you'll learn
  • What the three permission verdicts (allow / ask / deny) mean
  • How permission rules match a tool plus a pattern
  • The six permission modes and when to use each one
  • How auto mode replaces prompts with a safety classifier
  • How to build a sane starting allowlist that cuts prompts without losing safety
  • Where to store project vs. personal permission rules

Permissions decide what Claude Code can do without stopping to ask you. Tune them well and you get flow without losing control; tune them badly and you either rubber-stamp everything or drown in prompts.

The three verdicts​

Every potential action resolves to one of:

Press Enter or Space to flip the card. Use the left and right arrow keys to move between cards.Term shown.
1 / 3

Rules typically match a tool plus a pattern, e.g. allow Bash(npm run test:*) or deny Read(./.env).

Allow a tool + pattern

Bash(npm run test:*)

Deny a tool + pattern

Read(./.env)

Permission modes​

A mode sets the overall posture for a session. There are six. Cycle the common ones with Shift+Tab, or set permissions.defaultMode in settings.

ModeRuns without askingUse when
default (shown as Manual)Reads onlyDay-to-day work, sensitive changes
acceptEditsReads, file edits, common filesystem commandsA trusted, well-scoped editing session
planReads only; proposes, never editsBig/risky tasks — see Plan Mode
autoEverything, screened by a safety classifierLong tasks where prompt fatigue is the real risk
dontAskOnly pre-approved tools; everything else is deniedLocked-down CI and scripts
bypassPermissionsEverything, no checksSandboxes/containers only — never on a machine with secrets

Auto mode​

auto is the middle ground between prompting for everything and turning safety off. Instead of asking you, a separate classifier model reviews each action before it runs and blocks anything that escalates beyond what you asked for, touches infrastructure it doesn't recognise, or looks driven by hostile content Claude just read. Explicit ask rules still stop and ask you.

It blocks things like curl | bash, force pushes, production deploys and migrations, and sending secrets to external endpoints — while letting routine work (local edits, installing declared dependencies, read-only HTTP, pushing to your own branch) run straight through. If it blocks the same action repeatedly, auto mode pauses and hands prompting back to you.

Auto mode is not a safety guarantee — it reduces prompts, it doesn't remove the need to review sensitive operations. Availability depends on your plan, model, and (on Team/Enterprise) an admin toggle.

Watch out
  • bypassPermissions belongs in a sandbox. Running with all prompts off on your real machine is how an agent ends up touching something it shouldn't. Reserve it for disposable environments — if what you actually want is fewer prompts, use auto mode instead. See Hardening Autonomous Runs at /docs/security/hardening-autonomous-runs.

A sane starting allowlist​

The goal: pre-allow the safe, repetitive things; keep destructive things on ask or deny.

Guided walkthrough1 of 3
  1. Read files, run your test/lint/build commands, git status/diff.

Store project rules in settings.json (shared) and personal overrides in settings.local.json.

Pro tip
  • Let it learn from your prompts: approve the same safe command a few times and you'll know exactly what to add to your allowlist — turning repeated prompts into a one-time rule.
Key takeaways
  • Three verdicts: allow (no prompt), ask (default — pause and confirm), deny (never).
  • Rules match a tool plus a pattern, like Bash(npm run test:*) or Read(./.env).
  • Six modes set session posture: default (Manual), acceptEdits, plan, auto, dontAsk, bypassPermissions.
  • auto mode screens every action through a safety classifier instead of prompting you — that's the tool for prompt fatigue, not bypassPermissions.
  • Build an allowlist: allow safe + repetitive, ask for medium-risk, deny destructive.
  • Shared rules go in settings.json; personal overrides in settings.local.json.

Check yourself

0/5
  1. What does the default 'ask' verdict do for an action that is not explicitly allowed or denied?
  2. Which permission mode is safe ONLY in sandboxes or containers, never on a machine with secrets?
  3. You want far fewer permission prompts on a long task, but you still want a safety net. Which mode?
  4. Where should you store shared project permission rules versus personal overrides?
  5. Which of these belongs on the 'deny' list in a sane starting allowlist?

Next​