Permissions & Permission Modes
- 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
- Why auto mode is now the default on Pro / Max / Team plans (Aug 14, 2026) — and how to opt out
- 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:
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.
| Mode | Runs without asking | Use when |
|---|---|---|
default (shown as Manual) | Reads only | Day-to-day work, sensitive changes |
acceptEdits | Reads, file edits, common filesystem commands | A trusted, well-scoped editing session |
plan | Reads only; proposes, never edits | Big/risky tasks — see Plan Mode |
auto (the new default on Pro / Max / Team from Aug 14, 2026) | Everything, screened by a safety classifier | Long tasks where prompt fatigue is the real risk |
dontAsk | Only pre-approved tools; everything else is denied | Locked-down CI and scripts |
bypassPermissions | Everything, no checks | Sandboxes/containers only — never on a machine with secrets |
Auto mode is now Claude Code's default
Starting August 14, 2026, auto is the default permission mode for new sessions on Pro, Max, and Team plans. Anthropic's rationale (from their own testing of over 1,000 paid users): the classifier caught 89% of harmful actions vs 13.6% for manual review — because habituated users accepted about 97% of manual prompts without reading them.
Two carve-outs preserve intent:
- If you set
permissions.defaultModein your user settings, it stays put unless you accept a one-time in-app switch prompt. - If your organization manages the default (Team/Enterprise managed settings), nothing changes automatically.
You can always cycle modes mid-session with Shift+Tab. Related change already in effect on those plans: the classifier calls auto mode makes no longer count against your usage limits.
Opt in early (before Aug 14) — set auto as your default
~/.claude/settings.json
{
"permissions": {
"defaultMode": "auto"
}
}Stick with the old prompting behavior after Aug 14
~/.claude/settings.json
{
"permissions": {
"defaultMode": "default"
}
}How auto mode actually works
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, rm -rf on unresolved variables, transcript tampering, destructive git commands that discard uncommitted work, 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. If you run truly unattended (cron, cloud sessions, CI), pair it with Hardening Autonomous Runs — auto still isn't bypassPermissions.
- 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.
- Read files, run your test/lint/build commands, git status/diff.
- Installing dependencies, writing files outside the project, network calls.
- Reading secret files (.env, key files), force-push, rm -rf.
Store project rules in settings.json (shared) and personal overrides in settings.local.json.
- 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.
- 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.
- As of Aug 14, 2026, auto is the new default for new sessions on Pro / Max / Team plans; a defaultMode you set yourself stays in place, and organization-managed defaults are untouched.
- 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/6Next
- settings.json: The Config System
- Hooks — enforce rules deterministically, beyond allow/deny
- Sandbox Credential Masking — let
gh,npm, andawsauthenticate without the sandboxed command ever holding the real secret - Security & Responsible Use