How to Choose a Claude Code Permission Mode

Halfway through a long task, Claude Code asks you to confirm every file edit and every command. By the twentieth click, you start thinking: just switch on bypassPermissions and let it finish.

Prompts are tiring, but before you skip them, it helps to know what a permission mode actually controls. It isn't a safety-level slider. It answers one specific question: what happens to an operation that no permission rule matched. Each mode answers differently:

• some allow reads and ask about everything else;
• some accept file edits automatically;
• some hand review to a background classifier;
• some deny anything that would need a prompt;
• some ask about almost nothing.

So the choice depends on the task and the environment. Reading an unfamiliar project, making small iterative changes, and running unattended CI each call for a different mode. If fewer prompts appear, you should be able to say which ones disappeared and who is covering for them.

01 Modes Act After the Rules

A permission mode only handles operations that no rule matched. Claude Code checks deny, then ask, then allow, and only when none of them match does the mode decide. Your deny rules apply before the mode in every mode; how rules match is covered in why Claude Code denies a command you allowed.

The tighter your rules, the fewer operations are left for the mode to handle. For writing the allowlist itself, see 5 common gaps in Claude Code permission rules.

02 What Each of the Six Modes Allows

This table matches the Claude Code permission modes documentation. A few details are worth remembering:

• default is shown as Manual in the CLI, IDE extensions, and desktop app; default is its config value.
• Besides file edits, acceptEdits also approves common file commands such as mkdir, touch, mv, and cp. Critical paths and destructive operations still need ask or deny.
• The docs say that from v2.1.283, interactive terminal and VS Code sessions start in auto mode by default. To review every action yourself, choose Manual explicitly, for example with claude --permission-mode default.

03 Choose a Mode for the Task

Mode choice comes back to the task at hand.

• Reading an unfamiliar project: plan has a clear purpose. When you find something to change, adjust the task and the mode.
• Small, continuous changes in a familiar project: consider acceptEdits, and keep reviewing the diff.
• Unattended CI: with no one to answer prompts, consider dontAsk so unapproved actions simply fail.

auto's classifier reduces prompts, but deployments, credentials, and irreversible changes still need human review. The docs list what the classifier blocks by default, including downloading and executing code, sending sensitive data to external endpoints, production deploys and migrations, force pushes, and git reset --hard that would discard uncommitted work. Those blocks are a floor; they don't replace your own judgment about this task's boundaries.

Before using bypassPermissions, verify how the container or VM isolates files, network, and host access. Fewer prompts don't prove an operation is safe. The docs describe this mode's scope as "isolated containers and VMs only."

04 Switching and Setting a Default

In a terminal session, press Shift+Tab to cycle through the common modes, or set one at launch:

claude --permission-mode plan

Shift+Tab cycles default → acceptEdits → plan; from auto, the first press goes back to default. dontAsk isn't in the cycle; start with --permission-mode dontAsk instead.

Set a default mode with permissions.defaultMode in Settings, for example default. The docs note one restriction: setting the default to auto or bypassPermissions in a project's .claude/settings.json or .claude/settings.local.json doesn't take effect. Those two can only come from your own user settings, the command line, or organization policy, so a repository can't switch on the most permissive modes for you.

05 Two Easy-to-Miss Inheritance Problems

The first involves subagents. You give a read-only review agent permissionMode: plan and assume it won't edit files. The subagents documentation explains that when the main conversation is in bypassPermissions, acceptEdits, or auto, the subagent runs in that same mode and ignores the permissionMode you set. A read-only role still has to come from restricted tools; see a read-only code review subagent for Claude Code.

The second involves unattended runs. When Claude really does need to finish on its own, first restrict the filesystem and network with a container or VM, then use explicit allow rules or dontAsk mode so unapproved actions fail. The official CI example uses exactly that pairing: dontAsk with --allowedTools listing the precise allowed scope.

Back to that long task and its twenty confirmations. Instead of skipping every check, put the common safe commands in the allowlist and let the mode handle the few that remain. If you do need to open things up, isolate the environment first. With the right mode, you'll see fewer prompts and still know who is responsible for the ones that went away.