Claude Code Permissions: allow, ask, deny Rules and Modes

Claude Code controls tool use — editing files, running commands, accessing the web — through permission rules. You decide what runs automatically, what asks for confirmation each time, and what is blocked outright, using settings.json and permission modes. This guide covers the three rule types and their evaluation order, the configuration file levels, and the permission modes, based on the official documentation. (Details may change, so check the official permissions docs for the latest.)

Three permission rules

Permissions live in the permissions object of settings.json, split into three lists.

• allow — uses the tool automatically, without confirmation. Cuts down on repeated approvals.
• ask — prompts for confirmation whenever the tool is about to be used.
• deny — blocks the tool. The strongest rule.

Run /permissions in the terminal to see every active rule and which settings.json each one comes from.

Evaluation order — deny, then ask, then allow

Rules are always evaluated in the order deny -> ask -> allow, and the first match decides the outcome. Rule specificity does not change this order. For example, if an ask rule matches a command, it prompts first even when a more specific allow rule also matches. And a deny rule blocks the tool even in bypass mode.

Rule format and wildcards

Rules take the form Tool (the whole tool) or Tool(specifier) (a scoped pattern). The * wildcard is supported.

{
  "permissions": {
    "allow": ["Bash(npm run *)", "Bash(git status)"],
    "ask":   ["Bash(git push *)"],
    "deny":  ["Read(./.env)", "Read(./.env.*)", "Bash(rm -rf *)"]
  }
}

One important difference: a deny entry with just a tool name (e.g. Bash) removes the tool from Claude’s context entirely, so Claude never sees it. A scoped entry (e.g. Bash(rm *)) keeps the tool available and blocks only matching calls. MCP tools use a double-underscore format with no parentheses. New to MCP? See how to connect MCP.

Settings have levels

Settings can live at several levels, not just one. The main ones are the user level ~/.claude/settings.json (applies to every project), the project level .claude/settings.json (commit it to the repo to share with the team), and org-enforced managed (enterprise) settings. A managed deny cannot be undone by users, which makes it useful for enforcing a team-wide safety boundary. Exact precedence rules can vary by version, so check the official docs. A clean split is to use CLAUDE.md for what to build and settings.json for how to operate.

Permission modes

(Updated September 7, 2026 — this section was rewritten against the latest official permission-modes documentation.)

A permission mode sets which actions Claude can take in a session without asking you first. Where the rules above (allow, ask, deny) decide which tools, the mode decides how autonomous the baseline is. The official docs list six modes.

• auto — a separate classifier model reviews each action instead of you. Actions it judges safe run; risky ones are blocked. It is meant for long tasks you want to hand off. Anything matched by an explicit ask rule still prompts, even in auto mode.
• default (shown as Manual) — prompts before file edits, shell commands, and network access that no allow rule covers. Best for sensitive work or an unfamiliar codebase. The config value is default; Claude Code v2.1.200 and later also accept the alias manual.
• acceptEdits — file edits inside the working directory and common filesystem commands such as mkdir, mv, and cp run without a prompt. Suits a workflow where you review changes afterwards with git diff.
• plan — Claude reads and explores, then proposes a plan, and does not edit your source until you approve it. The status bar shows ⏸ plan mode on, and you can start in this mode with claude --permission-mode plan.
• dontAsk — anything that would prompt is denied automatically. Only tools pre-approved in your allow rules and read-only commands run, which makes it the mode for CI pipelines and scripts where nobody can answer a prompt.
• bypassPermissions (the CLI --dangerously-skip-permissions, often called “YOLO mode”) — skips prompts and safety checks alike. It is safe only in isolated environments such as containers, VMs, or ephemeral CI runners, where the environment itself is the safety boundary.

Which mode does a new session start in?

According to the official docs, on Pro, Max, and Team plans the built-in starting permission mode for a new terminal or VS Code session is auto mode (Claude Code v2.1.228 or later; v2.1.233 or later on native Windows). On an Enterprise plan or a Console API key, as well as in sessions routed through providers such as Amazon Bedrock and in non-interactive claude -p runs, sessions start in Manual (default). Two things take precedence over that built-in default:

• The claude --permission-mode <mode> flag (or --dangerously-skip-permissions) for that one session
• permissions.defaultMode in a settings file — except that auto and bypassPermissions do not take effect from a project’s .claude/settings.json or settings.local.json; put them in your user ~/.claude/settings.json or in managed settings

If your user settings already set a defaultMode other than auto, that value stays in force and Claude Code asks once whether to switch it. If an organization sets permissions.disableAutoMode to "disable" in managed settings, auto mode disappears entirely and sessions start in Manual. Auto mode is only available on supported models (on the Anthropic API: Opus 4.6 or later, Sonnet 4.6 or later, or a Fable model, which includes the current Opus 5, Sonnet 5, and Fable 5.1; the classifier itself runs on Claude Sonnet 5 by default); when the requirements are not met, a session that asked for auto starts in Manual instead.

Switching modes during a session

In the terminal, each press of Shift+Tab moves to the next mode. The official docs spell out the cycle:

• From auto mode, the first press switches to default; after that the cycle runs default → acceptEdits → plan → back to default.
• auto slots in after plan when your account and model support it, and bypassPermissions appears only in sessions started with it enabled. With both enabled the order is plan → bypassPermissions → auto.
• dontAsk never appears in the cycle; set it with --permission-mode dontAsk.

You do not need to memorize the order: keep pressing until the mode you want shows in the status bar. The VS Code extension uses the mode indicator under the prompt box and the desktop app uses the mode selector next to the send button for the same thing. Asking Claude in chat to change the mode does not work.

What holds in every mode

• deny rules block in all six modes, including bypass.
• Writes to protected paths such as .git/ and .claude/ are never auto-approved in any mode except bypassPermissions: Manual and acceptEdits prompt, auto routes the write to the classifier, and dontAsk denies it. In bypass mode, protected-path writes are allowed, which is one more reason to keep that mode inside isolated environments.
• rm and rmdir aimed at a critical path, such as the filesystem root, your home directory, or your working directory, still prompt even in bypass mode and go to the classifier in auto mode. No allow rule removes that check.

Safe defaults

• Protect secret files with deny — e.g. Read(./.env), Read(./.env.*), SSH key paths.
• Put hard-to-undo commands in deny — e.g. Bash(rm -rf *), force push.
• Move safe, repeatedly-approved commands (tests, lint) into allow so they do not break your flow.
• Use bypass mode only in isolated environments. For day-to-day work, stay in a mode that keeps some review in place: auto (classifier review), Manual, or acceptEdits.
• Sandboxing is a complementary layer, separate from permissions. When building automation, you can insert checks before and after tool runs with hooks.

New to Claude Code? Start with what Claude Code is and the install guide for the full picture.

The permission-modes section was re-checked against the official permission-modes docs on September 7, 2026; the remaining options and behaviors (rule syntax, defaultMode, disableAutoMode, /permissions) were re-checked against the official permissions doc on September 9, 2026 and may change by version. For details such as file precedence and sandbox setup, check the official permissions docs. This site is not an official Anthropic site.

Related articles

• Claude Code Installation Guide: native vs npm, Windows Included
• How to Use Claude Code: Real Usage After Install (Commands, VS Code)
• What Is Claude Code? A Beginner's Intro to the Terminal AI Agent
• Claude Code IDE Setup: Using VS Code and JetBrains (2026)
• Claude Code vs Cursor: Key Differences and Which to Choose