Short answer: rules under permissions in a settings file put each tool call in one of three lists: allow runs it, ask stops and asks you, deny refuses it whatever else says. Anything no rule mentions follows the permission mode, which by default asks.
Every time Claude Code wants to run a command, read a file or fetch a page, it checks your permission rules first. The rules decide one of three things: the call goes ahead, Claude Code stops and asks you, or the call is refused. Getting them right is the difference between being interrupted every ten seconds and letting an agent touch things it should not.
Where do permission rules live?
Permission rules sit under permissions in any of Claude Code's settings files:
{
"permissions": {
"defaultMode": "acceptEdits",
"allow": ["Bash(npm run *)", "Bash(git commit *)"],
"ask": ["Bash(git push *)"],
"deny": ["Read(./.env)", "Read(./secrets/**)"]
}
}Put rules that are about the project, such as never reading .env, in .claude/settings.json so the whole team gets them. Put rules that are about how you like to work in ~/.claude/settings.json. See which settings file wins for the full list.
What do allow, ask and deny do?
deny: never, whatever else says otherwise. Read this list first: nothing overrides a deny, including an allow that looks more specific.ask: stop and ask me. It beats an allow, which makes it the right home for anything that leaves your machine or costs money, such asgit pushor web requests.allow: stop asking me about these. The list that keeps permissions bearable; without it people turn the whole thing off.
The order is simple: deny beats ask, and ask beats allow, whichever settings file each rule is in.
How is a rule written?
A rule names a tool, and optionally what it applies to in brackets:
| Rule | Matches |
|---|---|
Bash(npm run *) | Any npm run command |
Bash(git push *) | Any git push |
Read(./.env) | Reading the .env file in the project |
Read(./secrets/**) | Reading anything under secrets/ |
WebFetch | Every web fetch |
Read | Every file read |
A rule without brackets covers every use of that tool.
What happens to everything no rule mentions?
defaultMode decides what happens to a call that none of your rules mention:
| Mode | What it does |
|---|---|
default | Asks about anything that changes something |
acceptEdits | Edits go through without asking; commands still ask |
plan | It may read and think, but not act |
bypassPermissions | Nothing asks. For a sandbox with no network, and nowhere else |
acceptEdits is a common choice for day-to-day work: file edits flow, and anything that runs a command still stops for you unless an allow rule covers it.
What is a safe place to start?
- Deny the secrets.
Read(./.env),Read(./secrets/**)and any key files your project has. - Ask for anything outbound.
Bash(git push *),WebFetch, and deploy commands. - Allow the loop you run all day. Your test command, your build,
git status,git diff, reading files. - Pick a mode. Start with
defaultoracceptEdits; neverbypassPermissionsoutside a sandbox.
Where can you check this?
How do you try rules before you trust them?
Config Studio for Claude Code has the permission rules as plain-language choices with one-click presets (secrets, destructive shell, force pushes, anything outbound, reading and looking around, running the tests), and a Try it tab that answers "Would this be allowed?" for a call you describe, so you can see which rule decides it. It writes the settings file for you and never touches your disk.
