Permissions Merge And Deny Beats Allow

Definition

Claude Code's permission model: allow/deny/ask rule arrays defined across every settings scope are merged into one rule set, and on any conflict deny always wins.

Key points

• Rules use patterns, e.g. Bash(npm *), Read(~/.zshrc), and the MCP form mcp__<server>__<tool>.
• Rules MERGE across scopes (Managed, CLI, Local, Project, User) rather than a higher scope replacing lower ones wholesale — this is why the Config Hierarchy precedence is about individual key conflicts, not blanket override for permissions.
• deny beats allow whenever both match a call.
• allowManagedPermissionRulesOnly makes only managed rules effective, blocking user/project rules entirely.
• Hot-reload: permission rules (like hooks and credentials) reload mid-session; model and outputStyle require a restart.
• CLI equivalents feed the same model: --allowedTools/--allowed-tools, --disallowedTools, --tools. See CI CD Headless Flags.

Why it matters for the exam

• D3 (20% of scored content) reliably tests the deny-beats-allow rule and that permission rules merge (rather than the top scope overriding). Pick the answer where a deny anywhere blocks an otherwise-allowed action.

Common gotchas

• Adding an allow in a higher scope does not override a deny in a lower scope — deny still wins.
• Permissions are probabilistic-free (deterministic), unlike CLAUDE.md; but for blocking a specific tool call with custom logic you still need a PreToolUse hook (see PreToolUse hook enforcement).
• allowManagedPermissionRulesOnly silently disables user/project rules.

See also

• Config Hierarchy
• Hook Exit Codes And JSON Output
• CI CD Headless Flags
• PreToolUse hook enforcement

Sources

• docs-tools-agents
• netlight-study-guide