Permissions Rule Builder

What Claude Code permissions do

Permissions decide, for every action Claude Code wants to take, whether it runs silently, pauses for your confirmation, or is blocked outright. They live in the permissions block of your settings.json, split into three lists - allow, ask, and deny - plus a defaultMode that governs anything none of your rules match. Getting this block right is the difference between an assistant that moves fast on safe work and one that could run a destructive command without you noticing.

The builder above lets you assemble rules visually. Pick a tool, type a pattern, and choose allow, ask, or deny for each rule. It emits a valid permissions object you paste straight into settings.json. The default set it starts with is a sensible baseline: read anything, edit source, run tests freely, confirm before pushing or fetching, and hard-block secrets and destructive commands.

The rule syntax

Every rule is written as Tool(pattern). The tool is one of Claude Code's built-in tools - Read, Edit, Write, Bash, WebFetch, WebSearch, Glob, or Grep. The pattern narrows what the rule applies to. For file tools like Read and Edit, the pattern is a path glob such as src/** or ./.env. For Bash, the pattern matches the command, and a trailing wildcard like npm run test:* covers a whole command family. Leaving the pattern empty makes the rule apply to the entire tool - useful when you want to ask before every WebFetch, regardless of URL.

• Read(**) - allow reading any file in the project.
• Edit(src/**) - allow edits only inside the src folder.
• Bash(npm run test:*) - allow any npm test script without prompting.
• Bash(git push:*) - match every git push variant so you can put it behind ask.
• Read(./.env) - name a secret file explicitly so you can deny it.
• WebFetch - with no pattern, the rule governs every fetch the tool makes.

How to think about allow, ask, and deny

Use allow for actions that are safe and frequent, where a prompt would just be friction - reading files, editing source, running your test suite. Use ask for actions that are usually fine but occasionally consequential, so you get a beat to review: pushing to a remote, fetching a URL, running a migration. Use deny for anything that should never happen unattended: opening secret files, running destructive shell commands, touching production credentials. The goal is to make the safe path frictionless and the dangerous path impossible.

The defaultMode fallback

Anything none of your rules explicitly match falls through to defaultMode. The default value prompts you on first use, which is the safe choice for most projects. acceptEdits auto-accepts file edits so you are only prompted for shell and network actions, which speeds up heavy refactor sessions. plan makes the session read-only for planning without changes. bypassPermissions skips all prompts - powerful in a locked-down container, but risky on a shared team file, so reach for it deliberately.

A safe starting policy

1. Allow Read(**) so the model can freely inspect the codebase.
2. Allow Edit on your source folders, not the whole disk.
3. Allow the specific Bash command families you trust, like your test and lint scripts.
4. Put network actions - WebFetch and git push - behind ask so you approve them each time.
5. Deny your real secret paths and destructive commands, and verify the deny patterns match where your keys actually live.

Common mistakes

• Allowing Bash without a pattern - that grants an unrestricted shell. Always scope Bash rules to command families.
• Relying only on allow lists for safety - without an explicit deny, a broad allow can reach files you did not intend.
• Denying the example ./.env but forgetting your real secret location - the deny list only protects what it names.
• Turning on bypassPermissions in a shared file - it removes confirmation prompts for the whole team.