Claude Code permission modes

What is a permission mode?

Anthropic’s Claude Code decides action by action whether it needs your answer first, and the permission mode you are in is the baseline for that decision. In its Manual mode, Claude Code stops and asks before most actions that edit files, run shell commands or reach the network. In its auto mode, a second model that it calls the classifier reviews those actions in your place, and its documentation lists which actions the classifier sees and which ones skip it.

Anthropic is clear that a mode is only the baseline. On top of it sit permission rules, which Anthropic lets you write to pre-approve or block a particular tool. It evaluates them in a fixed order (deny, then ask, then allow), and the first match decides the outcome, regardless of how specific the rules are. A deny rule blocks in every mode, its bypass-permissions mode included; an allow rule has no effect in bypass-permissions mode. It also makes the point that these rules are enforced by Claude Code itself and not by the model, so a line in your instructions changes what Claude tries to do but never what Claude Code permits.

The six modes

Manual — config value default

This is Anthropic’s most careful mode: Claude Code reads your files, and asks before most actions that edit a file, run a shell command or reach the network. It names it Manual in the command line, in the editor extensions and in the desktop app, and its config value is default, which is what its hooks, settings files and integrations use. It also accepts manual as an alias wherever you type the value, such as claude --permission-mode manual. It recommends it for reviewing every action yourself and for sensitive work.

Accept edits — acceptEdits

Anthropic’s acceptEdits mode lets Claude Code create and edit files in your working directory without asking, and it also auto-approves a short list of common filesystem commands: mkdir, touch, rm, rmdir, mv, cp and sed. It says those commands are also auto-approved when they carry a safe environment variable or a process wrapper in front of them, with touch the one exception, and that the auto-approval covers only paths inside your working directory or the extra directories you added.

Five things still prompt in this mode, in Anthropic’s account: a path outside that scope, a write to one of its protected paths, a recognised rm or rmdir removal of a critical path, a touch carrying an option, a glob or a prefix such as timeout 5 or LANG=C, and every other shell command apart from its built-in set of read-only commands. It also runs a symlink check, so a write that resolves outside your working directory is not auto-approved either. It suggests this mode when you would rather review the changes afterwards, in your editor or with a diff, than approve each edit as it happens.

Plan — plan

Anthropic’s plan mode tells Claude Code to research and propose changes without making them: it reads files, explores with shell commands and writes a plan, and edits stay blocked until you approve that plan, except in an interactive terminal session where bypass permissions are available. What happens to a shell command while planning depends on the session. Where its auto mode is available to that session and the plan-time setting is on (it ships it on by default), the classifier reviews the command instead of prompting you, and a command it rejects is blocked. Where auto mode is unavailable, Anthropic prompts you for anything outside its read-only set.

Anthropic’s plan mode is entered with Shift+Tab or by prefixing a single prompt with /plan, and left with Shift+Tab again. When the plan is ready, it offers you a choice: approve it and switch into auto mode, approve it and review each edit yourself, or keep planning.

Auto — auto

Anthropic’s auto mode lets Claude Code run actions without routine permission prompts, with the classifier checking each one first. It says an explicit ask rule still forces a prompt in this mode, and that it made auto mode the built-in starting mode for interactive terminal and editor sessions from Claude Code v2.1.283 onwards. It is careful about what it claims for the mode, and so is the next section — the classifier is worth understanding before you leave a long task running in it.

Don’t ask — dontAsk

Anthropic’s dontAsk mode is built for locked-down CI and scripted runs: Claude Code denies, rather than prompts, every call that would otherwise need your answer, so the session never sits waiting for input. It says an allow rule or an approved pre-tool hook still lets a call through, and that the actions needing no approval in Manual mode (file reads inside your working directory and the built-in read-only shell commands) keep working here. It also warns of one gap: a small add-on you installed can still approve some of the calls this mode denies. This mode never appears in its Shift+Tab cycle, so you set it with claude --permission-mode dontAsk.

Bypass permissions — bypassPermissions

Anthropic’s bypassPermissions mode disables the permission prompts and the safety checks, so tool calls run immediately, writes to its protected paths included. Two of its own warnings matter here: the actions no mode auto-approves still prompt even in this mode, and it says to use it only in an isolated environment such as a container or a virtual machine, because the mode offers no protection against prompt injection or unintended actions. It will not let you enter this mode from a session you did not start with it enabled, refuses it in a session started with --restricted, and refuses it outright when Claude Code runs as root or under sudo on Linux and macOS.

What no mode auto-approves

Anthropic keeps a short list of actions that no permission mode approves on its own, and that includes the mode that turns the checks off. Its list is:

• A tool matched by one of your own ask rules.
• A connector tool your organization has set to ask.
• A tool that needs an answer from you, such as Anthropic’s question tool or a tool from a connected server that is marked as requiring user interaction.
• A recognised rm or rmdir removal of a critical path — Anthropic counts the filesystem root, the top-level directories, your home directory, your working directory and its parents among them — which no allow rule and no hook can approve.
• Anthropic’s cross-session messaging safeguards.
• Reads outside your working directories while Anthropic’s setting for that is on, including a shell command the parser cannot trace, such as one that changes directory twice.

Anthropic protects a set of paths the same way, and this is the part people meet first. Writes to its protected paths are never auto-approved except in bypass-permissions mode, and in interactive plan-mode sessions where bypass permissions are available. Its protected directories include .git and .claude, and its protected files include shell startup files such as .bashrc and .zshrc. It runs this check before it evaluates the allow rules in your settings files, so a rule that looks like it should cover the write does not change the outcome, and in the modes that prompt it offers a session-scoped option instead.

Auto mode and the classifier behind it

Anthropic’s auto mode is the one that hands the review to a second model instead of to you. It says the classifier blocks anything that escalates beyond what you asked for, targets infrastructure it does not recognise, or looks driven by hostile content Claude read. Anthropic publishes long lists of what it blocks and allows by default: downloading and executing code, sending sensitive data to an external endpoint, production deploys and migrations, a force push, and a commit or push that would send secrets outside the repository are blocked, while local file work, installing dependencies your lock files already declare, and read-only requests go through. Anthropic lets an administrator add the repositories and services an organization trusts, so the classifier stops treating them as unrecognised.

Anthropic says the classifier does not simply wave an action through when it cannot decide. A blocked action appears in the permissions view under a recently-denied list, where Anthropic lets you approve it by hand. Three blocks in a row, or twenty in total, pause its auto mode and Claude Code resumes prompting you; approving the prompted action turns auto mode back on. When the classifier gives no verdict at all, Claude Code denies that action rather than run it unreviewed, and under server-side review, ten responses in a row with no verdict stop the turn. It also warns plainly that auto mode reduces prompts but does not guarantee safety, and recommends it for tasks where you trust the general direction rather than as a replacement for review on sensitive work.

An organization can take the two broadest modes away from everyone. Anthropic provides a setting an administrator puts in managed settings, where an individual cannot override it, to turn auto mode off; it says that removes it from the mode cycle and sends a session that asks for it to Manual instead. It provides a second setting for bypass-permissions mode in the same place. Auto mode also depends on the model Anthropic serves you: it lists the models that support it, and an older model cannot use it at all.

Which mode a session starts in

Anthropic takes the starting mode from the first of three things that applies. The first is the --permission-mode flag on the command line, and it treats the older --dangerously-skip-permissions flag as the same kind of choice. The second is permissions.defaultMode in a settings file. The third is its built-in default.

A project’s own settings files are the exception Anthropic draws. If a project’s .claude/settings.json or .claude/settings.local.json sets auto, it ignores that value and falls back to the built-in default rather than to a default mode set in your own user settings. If one of those two files sets bypassPermissions, it ignores that as well and starts the session in Manual. It says every other value applies from any settings file, and that where several files set the same thing, its settings precedence decides, so a project or managed value outranks your own.

Anthropic’s built-in default is auto mode for interactive terminal and editor sessions on Claude Code v2.1.283 and later, on every plan. On earlier versions Anthropic started those sessions in auto mode only on some plans and in Manual otherwise. It says a non-interactive run (claude -p, or an agent-SDK run with no mode set) starts in Manual, and that when the starting mode asked for is auto but auto mode is not available to the session, Claude Code starts the session in Manual rather than refusing to run. Once a session is going, it says its permission mode can be changed at any time: Shift+Tab cycles it in the terminal, and its editor extensions and desktop app offer a mode selector.

When Claude Code says a mode or the classifier is unavailable

Two messages get read as the same problem and are not. One says the permission mode is unavailable; the other says the classifier is unavailable. In Anthropic’s Claude Code they mean different things and the way out is different.

Permission mode is unavailable

Treat this one as a mode problem rather than a broken session. Anthropic documents the behaviour behind it as a fallback instead of a failure: when the flag, a settings file or the built-in default selects auto mode and auto mode is not available to that session, Claude Code starts the session in Manual rather than refusing to run. Anthropic lists why auto mode can be unavailable: a settings file turning it off, a model it does not support for the mode, an organization that has disabled it, or Anthropic having turned it off on its own side. A session that got that answer from either side keeps auto mode off until the session ends, so starting a new session later is what gets it back. The way out is to change the mode you are in: Shift+Tab cycles the modes in the terminal, and the editor extensions and the desktop app offer a mode selector. If the mode you want is not on offer at all, starting a new session is the other route back to a normal one.

The classifier is unavailable

A message that names a model and says Anthropic’s auto mode cannot determine the safety of an action is a transient classifier failure, and one action is denied rather than run unreviewed. Where a whole turn stops instead, that is a different symptom with its own steps: the Claude Code error messages guide covers what you see when the server returns no safety verdict, and what clears it.

Where Omniscio fits

Omniscio, the desktop app we make for running sessions of Anthropic’s Claude Code, answers its own version of that question with one setting of its own. Omniscio calls it the Agent Permission Level, and it has four levels, from most cautious to most trusting: Read-only, Guarded, Autonomous and Full trust. Omniscio’s Read-only level asks before any write or command, its Autonomous level lets edits and commands run inside your project and asks only before a write outside it, and its Full trust level never asks at all.

A brand-new Omniscio install starts on Guarded, which is the middle of that range: Omniscio makes an agent’s file edits inside your project automatically, and asks you before a shell command, before an edit to the agent’s own configuration files, and before a write outside the project folder. An install of Omniscio that already existed is treated differently on purpose. The first time it starts after this feature reached it, Omniscio pins the level to Full trust, so an upgrade does not greet you with a wave of approval prompts you never asked for. That migration runs once inside Omniscio, and Omniscio never overrides a level you choose yourself later.

Below Full trust, Omniscio always asks before an agent touches a genuinely sensitive file: an SSH key, a cloud credential, a system file, a shell startup file. Full trust is Omniscio’s deliberate exception to that, because full trust is what it says: at that level Omniscio auto-approves everything, sensitive files included.

That is the part to weigh before you choose it. At Full trust an agent can change any file your account can reach, SSH keys and cloud credentials included, without asking you first. Omniscio makes one exception at every level, Full trust included: an agent it connects to through an outside engine, such as Kimi Code, Hermes or DSH, cannot touch a sensitive file at all. Use Full trust only where you are content for that reach, and Guarded wherever you are not; Guarded is the level Omniscio hands a first-time user, and it keeps the sensitive-file prompt.

Omniscio tightens a few cases without being asked. A session that an inbound email started is locked down harder: it cannot perform risky operations at all, and Omniscio keeps its sensitive-file prompt on that session even when you are on Full trust. The same goes for two sessions Omniscio starts on purpose, the Chief of Staff session used by Simple Mode, which runs at Read-only, and the guided app tour, which runs at Guarded, so both keep the sensitive-file prompt too. A pin like that can only ever make a session more cautious, never less, and nothing outside those sessions changes.

You choose the level for Omniscio in one of two places. Omniscio’s onboarding has a step called Agent Access, in the personalize part of setup just before the theme picker, which shows the four levels as cards and starts on Guarded. Afterwards it lives in Omniscio’s Settings, under Workflow, where Omniscio labels the dropdown Agent Permission Level and places it just above its Auto-Approve Plans and Auto-Approve Config File Writes toggles. Whichever way you pick it in Omniscio, the level applies straight away.