iTechGuides is reader-supported. When you buy through links on our site, we may earn an affiliate commission. As an Amazon Associate I earn from qualifying purchases. Learn more
Claude Code asks before it runs many tools, and you control how much it asks. Two settings do that work. A permission mode sets the overall approval behavior for a session. A permission rule matches a specific tool use and allows, asks about, or denies it. Beginners should start with a mode that keeps you reviewing actions, then add narrow rules for commands you run repeatedly. Organization-managed settings can override both, so check those too if you work on a company machine or repository.
The rules and modes below reflect Anthropic’s Claude Code permissions and settings documentation as checked in October 2026. These pages change between releases, so confirm the current mode names and rule behavior on the Configure permissions page before you rely on them.
![Claude AI for Beginners Bible: [5 in 1] The Ultimate Guide to Automate Your Work, Save Hours Every Week, and Use AI for Real-World Results](https://m.media-amazon.com/images/I/415+fSJacsL._SL160_.jpg)
Two layers: modes and rules
It helps to keep the two layers separate, because most confusion comes from mixing them up.
- Modes describe the session as a whole. They decide, in general terms, whether Claude Code pauses for approval, how it treats file edits, and whether it works in an exploration-only way.
- Rules describe individual actions. A rule such as
Bash(npm run build)says that one specific command may run without a prompt, or that one kind of action is always blocked.
A mode sets the baseline, and rules refine it for particular tools. Rules are where allowlisting happens.
#1 Best Overall
Permission modes
The current documentation lists six modes. The table summarizes each one in plain language; the permissions page holds the exact definitions.
| Mode | What it does, in plain terms | Suitable for a beginner? |
|---|---|---|
default |
Ordinary permission prompts for actions that need approval. | Yes. This is the one to start with. |
acceptEdits |
Changes how file edits are approved, so you are asked less often about edits. | Yes, once you are comfortable reviewing edits. |
plan |
Exploration without editing source files. The documentation notes specific qualifications to this. | Yes, for reading and planning a change. |
auto |
Uses a background classifier to judge actions instead of prompting for each one. | Not as a first mode. Learn how prompts work first. |
dontAsk |
Denies any call that would otherwise prompt, so unapproved actions simply do not run. | Only when you have already defined the rules you want. |
bypassPermissions |
Skips permission prompts, subject to documented exceptions. | No. See the warning below. |
Bypass mode is not a beginner default
The permissions documentation says: “Only use this mode in isolated environments like containers or VMs where Claude Code can’t cause damage.” Use bypass mode only in an environment you can throw away. A container or virtual machine limits what Claude Code can reach, but it does not make every action safe, so treat the isolation as a condition you have verified rather than a guarantee.
How permission rules are written
The documentation states the format directly: “Permission rules follow the format Tool or Tool(specifier).”
- A bare tool name, such as
Bash, matches every use of that tool. A bareReadmatches every file read. - A specifier narrows the match. Examples from the official examples include
Bash(npm run build)for one command,Read(./.env)for one file path, andWebFetch(domain:example.com)for one domain.
The difference between a bare name and a specifier is the most important idea for a beginner. A bare name is convenient and broad. A specifier is narrower and easier to reason about.
Allow, ask, and deny
Rules can be sorted into three outcomes: allowed without a prompt, always asked about, or denied. Deny rules are useful for files you never want Claude Code to read. For example, a deny rule for Read(./.env) keeps a local secrets file out of reach even when other reads are approved. Deny rules and allow rules can be combined, but read the settings page to confirm how they interact in your setup.
Bash rules need extra care
Bash is the tool where allowlists most often surprise people, for three reasons documented on the permissions page:
Rank #4
- The
*wildcard matches arbitrary text. Place it after the subcommand.Bash(git log *)allows Git log commands with any arguments.Bash(git *)allows every Git command, including ones that change repository state. - Compound commands are split. The documentation describes shell operators and says each relevant subcommand has to match a rule separately. Allowing the first part of a chained command does not approve the rest.
- Some commands run other commands. The permissions page documents cases where a rule does not match the way a novice would expect, including wrappers and commands that launch other commands. Read that section before allowing a broad Bash pattern.
An allow rule does not make a command safe. It only removes one prompt. Keep the rule as narrow as the task allows.
The Tool Desk
Outbyte Driver Updater FREEScan for outdated or missing drivers - takes under a minuteDriver Scan →Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Where settings live
Rules and mode defaults are stored in settings files, and each file has a scope. The settings documentation describes four.
| Scope | File or source | Who it applies to | Commit to version control? |
|---|---|---|---|
| User | ~/.claude/settings.json |
You, across every project on this machine | Not applicable. It lives in your home directory. |
| Shared project | .claude/settings.json |
Everyone working in the repository | Yes. This is where team conventions belong. |
| Project local | .claude/settings.local.json |
You, in this one project | No. Claude Code keeps it out of commits when it creates the file. If you create it by hand, add it to .gitignore yourself. |
| Managed | Organization-deployed managed settings | Everyone covered by the organization’s policy | Set by administrators. Ordinary user settings generally cannot override it. |
Settings are not simply replaced file by file. The Settings files and precedence page explains priority, and it notes that some lists are merged rather than overwritten. If Claude Code behaves differently from what one file suggests, the other scopes are the first place to look.
CLI flags for a single session
The CLI reference documents three flags that affect a session without editing any file:
--allowedTools(also accepted as--allowed-tools) lists tools or specifiers that may run without a prompt.--disallowedTools(also--disallowed-tools) lists deny rules.--permission-modeselects a mode at startup.
A flag applies only to the session you start. Settings files persist according to their scope. The reference also lists --dangerously-skip-permissions, which skips prompts and corresponds to bypass mode, so the isolation warning above applies to it. Check the exact argument format for multiple values on the CLI reference page, because flag syntax is version-dependent.
Set up a permissions baseline, step by step
- Start in default mode. Open a terminal in your project folder and run
claude. Do not pass a bypass flag. - Check the active mode. Inside the session, run
/permissionsto see the rules currently in effect. Recent Claude Code versions provide this view; if your version does not, read the settings files directly. - Approve one-off actions only. When a prompt appears, choose approval for that single action unless you have reviewed the exact command and expect to repeat it.
- Review any “always allow” choice before saving. A persistent approval is written to your local settings. Confirm the rule text in the prompt is as narrow as you intend.
- Add a narrow rule by hand if needed. Open
~/.claude/settings.jsonfor a personal rule across projects, or.claude/settings.local.jsonfor one project. Use this shape:
{
"permissions": {
"allow": [
"Bash(npm run build)"
],
"deny": [
"Read(./.env)"
]
}
}- Put team conventions in shared project settings only after agreeing on them. Edit
.claude/settings.json, review the diff, and commit it like other project configuration. - Check your managed policy. If your organization deploys managed settings, a local rule may not take effect. Ask your administrator what the policy allows rather than assuming your file wins.
Deciding what to allow
Use these questions in order when you are unsure whether a tool use belongs on the allowlist:
- Is this a one-off exploration? Keep the prompt. Approve the single action.
- Is it a command you run repeatedly and understand completely? Consider a narrow allow rule with an exact command or a wildcard after the subcommand.
- Could it change files, reach the network, or affect data outside the project? Keep the prompt, or add a deny rule.
- Does the rule affect teammates? Put it in shared project settings and get agreement first.
- Is the policy managed by an organization? Confirm the policy before adding a local exception.
Troubleshooting unexpected prompts or silent behavior
- A command you allowed still prompts. Compare the rule text with the exact command. A specifier that names one subcommand does not cover a variant with different arguments, and a chained command needs each part to match.
- A broad rule seems to allow more than expected. Narrow it to the subcommand you need, then test with a harmless command.
- A rule in your file has no effect. Check whether a managed policy, a flag, or another scope takes priority, using the settings precedence page.
- A teammate sees different behavior. Compare your
.claude/settings.local.jsonwith their setup. Local files are personal and do not travel with the repository.
Access and setup
Claude Code setup and the subscription plans that include it are described on the Set up Claude Code page. Access terms are separate from permission settings, so review that page for plan details rather than relying on this guide for them.
Quick Recap
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.
