Claude Code Permissions: Rules, Modes, and How Approvals Are Saved
Needs reviewLast verified August 12, 2026·4 min read
This guide explains how Claude Code's permission system works based on Anthropic's documentation. It covers the tiered approval model for read-only tools, Bash commands, and file edits; where permanent approvals are saved; how allow, ask, and deny rules are evaluated; the difference between bare tool-name deny rules and scoped pattern rules; the Ctrl+E command explanation shortcut; and the permission modes you can set with defaultMode, including default, acceptEdits, plan, and auto.
How the tiered permission system works
Claude Code uses a tiered permission system to balance power and safety. Different tool types have different approval requirements:
Read-only tools (file reads, Grep): no approval required within the working directory and any additional directories.
Bash commands (shell execution): approval required, except for a built-in set of read-only commands. Choosing "Yes, don't ask again" saves the approval permanently, per repository and command.
File modification (edit/write files): approval required. "Yes, don't ask again" lasts only until the session ends and is not saved to a file.
Where permanent approvals are saved
When an approval saves permanently (such as for a Bash command), Claude Code writes the rule to .claude/settings.local.json at the root of the git repository, resolved through worktrees to the main checkout. That rule then applies to future sessions anywhere in the repository, including sessions started in subdirectories and in worktrees.
Outside a git repository, or when the repository root is your home directory, Claude Code saves the rule in the directory you started it from.
Note a version-related behavior change: before v2.1.211, Claude Code always saved the rule in the starting directory, so an approval granted in a worktree or subdirectory didn't apply to the rest of the repository. Rules that earlier versions saved in a subdirectory or worktree still apply to sessions started there.
Explaining a command before approving it
On a Bash or PowerShell permission prompt, press Ctrl+E to show an explanation of the command: what it does, why Claude is running it, and what could go wrong, labeled Low risk, Med risk, or High risk.
Claude Code only sends the command and Claude's own description of the call to the model when you press Ctrl+E, not on every prompt. Showing the explanation doesn't run the command; press Ctrl+E again to hide it.
To turn the shortcut off, set permissionExplainerEnabled to false in ~/.claude.json.
Managing rules with /permissions
Use /permissions to view and manage Claude Code's tool permissions. The UI lists all permission rules and the settings.json file each rule comes from. There are three rule types:
Allow rules let Claude Code use the specified tool without manual approval.
Ask rules prompt for confirmation whenever Claude Code tries to use the specified tool.
Deny rules prevent Claude Code from using the specified tool.
Rule evaluation order
Rules are evaluated in order: deny, then ask, then allow. The first match in that order determines the outcome, and rule specificity doesn't change the order.
This has practical consequences. A broad deny rule like Bash(aws *) blocks every matching call, including calls that also match a narrower allow rule like Bash(aws s3 ls) — a deny rule can't carry allowlist exceptions. The same precedence applies between ask and allow: a matching ask rule prompts even when a more specific allow rule also matches the same call.
Bare tool names vs. scoped patterns
Deny rules behave differently depending on their form:
A bare tool name like Bash removes the tool from Claude's context entirely, so Claude never sees it.
A scoped rule like Bash(rm *) leaves the tool available and blocks matching calls when Claude attempts them.
One exception: bare-name removal applies to every tool except EndConversation. A deny rule can't remove EndConversation while any other tool remains, and an ask rule never prompts for it.
Rules are enforced by Claude Code, not the model
Permission rules are enforced by Claude Code, not by the model. Instructions in your prompt or CLAUDE.md shape what Claude tries to do, but they don't change what Claude Code allows. To grant or revoke access, use /permissions, permission rules, a permission mode, or a PreToolUse hook.
Permission modes
Permission modes control how Claude Code approves tool calls. Set the defaultMode in your settings files. The documented modes include:
default — standard behavior: prompts for permission on first use of each tool. Labeled Manual in the CLI, the VS Code and JetBrains extensions, and the desktop app, and Claude Code accepts manual as an alias. The label and alias require Claude Code v2.1.200 or later; the desktop app's label doesn't depend on your CLI version.
acceptEdits — automatically accepts file edits and common filesystem commands such as mkdir, touch, mv, and cp for paths in the working directory or additionalDirectories.
plan — Claude reads files and runs read-only shell commands to explore but doesn't edit your source files; with auto mode available, classifier-approved commands also run. Labeled Plan in the CLI and the VS Code extension.
auto — auto-approves tool calls with background safety checks that verify actions align with your request.
Sharing permission settings
Permission settings can be checked into version control so every developer in your organization shares them, while each developer can still customize their own.
claudedetails.com is an independent publication and is not affiliated with, endorsed by, or sponsored by Anthropic. "Claude" is a trademark of Anthropic, PBC, used here for identification purposes only. Product details can change — always confirm specifics on Anthropic's own site before making decisions based on this post.
FAQ
Where does Claude Code save permissions when I click "Yes, don't ask again"?
For permanently saved approvals such as Bash commands, Claude Code writes the rule to .claude/settings.local.json at the root of the git repository, resolved through worktrees to the main checkout. Outside a git repository, or when the repository root is your home directory, the rule is saved in the directory you started Claude Code from. File-modification approvals are not saved to a file — they last only until the session ends.
Can an allow rule override a deny rule in Claude Code?
No. Rules are evaluated in order: deny, then ask, then allow, and specificity doesn't change that order. A broad deny rule like Bash(aws *) blocks every matching call even if a narrower allow rule like Bash(aws s3 ls) also matches, so a deny rule can't carry allowlist exceptions. The same precedence applies between ask and allow.
How do I see what a command does before approving it in Claude Code?
On a Bash or PowerShell permission prompt, press Ctrl+E to show an explanation covering what the command does, why Claude is running it, and what could go wrong, labeled Low risk, Med risk, or High risk. Showing the explanation doesn't run the command. To disable the shortcut, set permissionExplainerEnabled to false in ~/.claude.json.
What's the difference between denying "Bash" and denying "Bash(rm *)"?
A bare tool name like Bash removes the tool from Claude's context entirely, so Claude never sees it. A scoped rule like Bash(rm *) leaves the tool available but blocks matching calls when Claude attempts them. The one exception is EndConversation: a deny rule can't remove it while any other tool remains.
This guide walks through the everyday prompt patterns Anthropic documents for Claude Code: getting an overview of an unfamiliar codebase, locating relevant files, fixing bugs from error messages, refactoring legacy code safely, adding tests for uncovered code, creating pull requests, and generating documentation. It also notes related workflows the docs cover, such as resuming sessions, running parallel sessions with worktrees, planning before edits, delegating research to subagents, and piping Claude into scripts.
Claude Code has no React-specific mode — what actually makes it effective on a React codebase is the same CLAUDE.md and permissions setup that works on any project, applied deliberately. This guide walks through what to put in CLAUDE.md for a React app, which commands to allow, and how to structure a component or test-fixing session.
This guide explains how to create a custom Claude Code plugin from scratch. It covers when to use a plugin versus standalone configuration in the .claude directory, how to structure a plugin directory with a .claude-plugin/plugin.json manifest, how to add a skill using a SKILL.md file, how to test the plugin locally with the --plugin-dir flag, and how to make skills accept user input with the $ARGUMENTS placeholder. It is based on Anthropic's documentation for Claude Code plugins.
ClaudeDetails