How to Manage Permissions in Claude Code

Claude Code can run shell commands, edit files, and reach the network, so it asks before doing anything sensitive rather than acting blindly. The permission system is how you decide what needs your approval, what runs freely, and what is blocked outright. Learning it lets you move faster on trusted work while keeping guardrails on the risky parts. Here is how it works in August 2026.

If you have not set up the tool yet, start with installing Claude Code and browse the full Claude Code hub for related guides.

How the permission system works

Claude Code uses a tiered system that balances power and safety. By default:

• Read-only actions (reading files, grep, and a built-in set of read-only shell commands) run without asking, as long as they stay inside your working directory.
• Bash commands ask before running, except for that read-only set.
• File edits and writes ask before changing anything.
• Web fetches ask, except for a small set of preapproved documentation domains.

When a prompt appears, you can approve it once, or choose “Yes, and don’t ask again” to save a standing rule. One important detail: these rules are enforced by Claude Code itself, not by the model. Instructions in your prompt or your CLAUDE.md shape what Claude tries to do, but they never change what Claude Code actually allows.

Allow, ask, and deny rules

You control permissions with three kinds of rule, set under a permissions key in a settings file:

• Allow rules let Claude use the tool without asking.
• Ask rules prompt for confirmation every time.
• Deny rules block the tool entirely.

Rules are evaluated in a fixed order: deny first, then ask, then allow. The first match wins, and a more specific rule does not jump the queue. So a broad Bash(aws *) deny rule blocks a call even if a narrower Bash(aws s3 ls) allow rule also matches it.

Each rule is written as Tool or Tool(specifier). A bare tool name matches every use of that tool; a specifier narrows it down. Here is a small example that allows npm and git commit commands, blocks git push, and refuses to read env files:

{
  "permissions": {
    "allow": [
      "Bash(npm run lint)",
      "Bash(npm run test:*)",
      "Bash(git commit *)"
    ],
    "deny": [
      "Bash(git push *)",
      "Read(./.env)",
      "Read(./.env.*)"
    ]
  }
}

A few things worth knowing about the syntax:

• Bash wildcards. Bash(npm run build) matches that exact command. Bash(npm run test:*) (or the equivalent Bash(npm run test *)) matches any command starting with npm run test. The :* suffix is just another way to write a trailing wildcard. Claude Code understands shell operators, so Bash(safe-cmd *) will not quietly approve safe-cmd && other-cmd; each part of a compound command is checked on its own.
• Files. Use Read(./.env) or Read(./secrets/**) to block reads, and Edit(...) to control edits. Edit rules apply to all the built-in tools that change files, and a Read deny rule also blocks editing or writing that same path.
• Web. WebFetch(domain:example.com) matches fetches to that domain. A bare WebFetch matches all of them.
• MCP tools. Rules like mcp__github__get_* scope down to a specific server’s tools. See setting up MCP in Claude Code for how those servers are named.

Where the rules live

Permission rules are read from settings.json files at three scopes, and Claude Code merges the lists together so each file can add to the others:

• User (~/.claude/settings.json): your personal rules across every project on the machine.
• Shared project (.claude/settings.json): team rules. Commit this to your repo so everyone who clones it gets the same permissions.
• Project local (.claude/settings.local.json): your private per-project rules, not meant to be committed.

When you answer a permission prompt with “Yes, and don’t ask again”, Claude Code saves that approval as an allow rule in your local file automatically, so you rarely have to hand-edit JSON for everyday approvals. Settings files are strict JSON, so a stray comment or trailing comma will make Claude Code report a settings error.

The /permissions command

You do not have to edit files by hand to see or change your rules. Type /permissions in Claude Code to open a dialog that lists every active rule and which settings.json file it came from. From there you can add or remove allow, ask, and deny rules, and Claude Code applies the change right away, even mid-task. This is the quickest way to grant a new command, tighten something up, or figure out why a particular action keeps prompting.

Permission modes

A permission mode sets how much Claude can do in a whole session without asking. Press Shift+Tab in the CLI to cycle through them, and the status bar shows which one is active:

Mode	What it does	Best for
default (Manual)	Prompts on first use of each tool	Sensitive or unfamiliar work
acceptEdits	Auto-accepts file edits and common file commands (mkdir, touch, mv, cp) in your working directory	A trusted task where approving every edit is tedious
plan	Reads files and runs read-only commands to draft a plan, but edits nothing until you approve it	Scoping a change before any code is touched
bypassPermissions	Skips permission prompts almost entirely	Only isolated environments like a container or VM

You can also set the starting mode with the --permission-mode flag (for example claude --permission-mode plan) or by setting permissions.defaultMode in a settings file so every session starts that way.

Safety guidance

A few habits keep the permission system working for you rather than against you:

• Keep deny rules on the sensitive stuff. Blocking Read(./.env) and similar paths means a stray command can’t leak secrets, and the rule applies to Claude’s file tools and to shell commands like cat that it recognizes.
• Be specific with Bash allow rules. A pattern meant to restrict arguments is fragile. Bash(devbox run *), for instance, would allow anything after run. Prefer narrow rules like Bash(npm test) over broad ones.
• Treat bypassPermissions with care. It skips prompts, including writes to protected paths like .git and .claude, so only use it in an isolated environment like a container or VM where Claude Code cannot do damage. Do not reach for “dangerously skip permissions” on your everyday machine.
• Commit shared rules, keep personal ones local. Put team-wide permissions in .claude/settings.json and your own exceptions in .claude/settings.local.json.

Keep going

Permissions are one piece of running Claude Code well. Pair this with Claude Code memory and CLAUDE.md to guide what Claude tries to do, hooks to enforce your own rules automatically, slash commands to speed up your workflow, and subagents for larger tasks. Running Claude Code inside your editor? See setting it up in your IDE. If you want the bigger picture on working with AI tools, our AI course covers it end to end, and you can start with the free lessons too.