Designing Your Allowlist and Denylist
Allowlists and denylists are the rule layer that sits on top of permission modes. They let you precisely control which specific actions run without prompting — and which ones are hard-blocked regardless of mode.
Quick Reference
- →Allowlist: auto-approve matching actions without prompting
- →Denylist: hard-block matching actions regardless of mode
- →Rule syntax: Tool, Tool(exact), Tool(prefix*), Tool(*middle*)
- →File path rules: Read(/src/*), Edit(.env*) — gitignore-style patterns
- →MCP tools: mcp__server__tool or mcp__server__* for all tools from a server
- →Allow arrays merge across user/project/local scopes — all are active at once
- →/permissions → Recent tab: fastest way to build allowlist from real usage
- →Deny rules in .claude/settings.json take precedence over user settings
Rules Layer on Top of Modes
Permission modes set the baseline behavior — what gets auto-approved or auto-denied by default. But modes are coarse. dontAsk denies everything not on the allowlist; default prompts for anything that writes. Rules let you carve out specific exceptions without changing the mode.
Allowlist rules say: approve this exact action without prompting, even if the mode would normally prompt. Denylist rules say: block this action absolutely, even if the mode would normally approve it. Together they give you surgical control over Claude's permissions.
Deny rules always win over allow rules. If an action matches both an allow and a deny rule, it is blocked. This is intentional — you can write broad allow patterns without worrying that a specific dangerous command slips through.