Permission Modes: Six Settings, One Right Choice
- Recognize what each of the six permission modes auto-approves and what it still requires manual review for
- Choose the right mode for interactive development, code review, CI/CD pipelines, and isolated container environments
- Configure permission modes at startup, mid-session, and as a persistent default without reducing organizational safety guarantees
The Mode Is the First Decision
Before any permission rule, sandbox configuration, or classifier setting applies, there is a permission mode. The mode determines the baseline: what Claude Code auto-approves without asking, what it prompts for, and what it flat-out denies. Everything else in the safety stack layers on top of that baseline. Choosing the wrong mode for the context means every downstream control is working against an overpermissive foundation.
Claude Code offers six modes. They are not a dial from "safe" to "fast" — each is designed for a specific context, and using one outside its intended context creates risk. This lesson covers what each mode does, when to use it, and how to configure it at the right scope.
The Six Modes
Reads only. File edits, shell commands, and network requests prompt before running. The right starting point for any unfamiliar codebase or sensitive repository.
Auto-approves file edits and a fixed set of filesystem shell commands (mkdir, touch, rm, rmdir, mv, cp, sed) within the working directory. Everything else still prompts.
Read-only, like default, but tells Claude to explore and propose without making changes. Use it when you want to understand a codebase or review a change plan before committing to execution.
Auto-approves most tool calls via a background classifier that reviews each action. Designed for long autonomous tasks. Requires specific models and plan/Owner enablement on Team and Enterprise.
Auto-denies every tool call not explicitly in your permissions.allow list. Only pre-approved tools can execute. The right choice for CI pipelines where you define exactly what Claude may do.
Skips all permission checks and protected-path guards. No classifier, no prompts. Only valid inside an isolated container or VM where Claude cannot affect the host system.
acceptEdits: Iterating Without Interruption
The most common mode for active development is acceptEdits. It auto-approves file edits and the six filesystem commands — but only for paths inside your working directory or additional directories you have explicitly added. A path outside that scope still prompts, as do all other Bash commands. This means mkdir src/components runs without asking, but npm install still requires approval.
The status bar shows ⏵⏵ accept edits on while this mode is active. Press Shift+Tab once from Manual mode to enter it, or set it as the default for a project:
{ "permissions": { "defaultMode": "acceptEdits" } }Use acceptEdits when you want to review changes in your editor or via git diff after the fact rather than approving each edit inline. It is not appropriate for repositories where writes to any file warrant human review — use Manual mode there.
Plan Mode: Look Before You Leap
Plan mode (Shift+Tab again from acceptEdits, or --permission-mode plan at startup) tells Claude to read and explore without making any edits. Shell commands for exploration still run; writes are blocked. Use it when you inherit a codebase and want a structural overview, or when the right approach is genuinely unclear and you want a written plan to review before execution begins.
When Claude finishes planning, it presents the plan and asks how to proceed. You can approve and switch to any other mode, keep refining with feedback, or press Ctrl+G to open the plan in your editor and annotate it directly before Claude continues.
Auto Mode and Its Prerequisites
Auto mode eliminates routine permission prompts by routing each tool call through a classifier that decides whether it aligns with your request. It is designed for long tasks where prompt fatigue becomes a problem — but it has hard prerequisites that matter for deployment planning.
Model requirements: On the Anthropic API, Opus 4.6 or later, or Sonnet 4.6 or later. On Amazon Bedrock, Google Cloud's Agent Platform, Microsoft Foundry, and signed-in Claude apps gateway sessions, only Sonnet 5, Opus 4.7, and Opus 4.8 are supported. Haiku, Sonnet 4.5, Sonnet 4.6, and all claude-3 models are not supported on those providers. Plan requirements: Available on all plans. Admin requirements: On Team and Enterprise, an Owner must enable auto mode in Claude Code admin settings before users can turn it on. Administrators can also lock it off via managed settings.
Auto mode is a research preview. It reduces prompts but does not guarantee safety — use it for tasks where you trust the general direction.
dontAsk for CI Pipelines
In CI/CD environments, you want deterministic behavior: Claude executes exactly the tools you pre-approved, denies everything else, and never waits for a human to answer a permission prompt. That is dontAsk mode. Set it with --permission-mode dontAsk and pair it with a tight permissions.allow list that names every tool Claude needs.
Note that explicit ask rules are also denied in dontAsk mode — Claude Code auto-denies rather than prompting, making the mode fully non-interactive. If your allow list is incomplete and Claude hits a tool call that is not on it, the action is silently denied and the task may fail. Test your allow list interactively first.
bypassPermissions: The Container-Only Mode
bypassPermissions disables all permission checks, all protected-path guards, and the auto-mode classifier. It is the fastest mode and the most dangerous one. The only valid use case is an isolated container or VM where Claude cannot affect the host system — a dev container with no network access, a CI VM that is destroyed after each run, or a sandbox environment specifically designed for unrestricted agent execution.
Claude Code refuses to start in bypassPermissions when running as root or under sudo — the combination of no permission checks and root access is explicitly blocked. Use a dev container configuration that runs as a non-root user. The --dangerously-skip-permissions flag is equivalent to bypassPermissions.
Self-locking: Both disableBypassPermissionsMode and disableAutoMode work from any settings scope, not just managed settings. A developer can add either to their own ~/.claude/settings.json to permanently prevent those modes from appearing in their Shift+Tab cycle — a useful personal safety constraint for anyone who works regularly in production repositories.
Switching Modes
Shift+Tab cycles through the modes in the default cycle: Manual → acceptEdits → plan. Auto mode appears in the cycle when your account meets the requirements. bypassPermissions appears only after you start with an enabling flag. dontAsk never appears in the cycle — set it at startup with --permission-mode dontAsk.
To set a persistent default for a project, add defaultMode to .claude/settings.json. To set a user-wide default, add it to ~/.claude/settings.json. Managed settings can enforce a floor that project and user settings cannot lower.
- The mode sets the baseline before any rule, sandbox, or classifier configuration applies — choosing the wrong mode for the context undermines every downstream control.
- acceptEdits auto-approves file edits and six filesystem commands (mkdir/touch/rm/rmdir/mv/cp) inside the working directory only — any path outside that scope and all other Bash commands still prompt.
- Auto mode has hard prerequisites: specific model versions, Owner enablement on Team/Enterprise, and provider compatibility — Haiku, Sonnet 4.5, and claude-3 models are unsupported on any provider.
- bypassPermissions skips all checks including protected paths and is refused when running as root — only use it inside an isolated container running as a non-root user.
- disableBypassPermissionsMode and disableAutoMode work from any settings scope — a developer can self-lock these modes in their own user settings, not just through managed organizational policy.