Learn · Permissions, hooks & security · CCAR-F

Permission rules and modes

Deny, then ask, then allow: how Claude Code decides whether a tool call runs, the rule syntax, and which permission mode fits which job.

Key ideas

Rules live in permissions.allow, ask and deny; evaluation order is deny, then ask, then allow, first match wins.
Unmatched actions prompt the user: the default fails closed.
Deny beats allow across every settings scope; a narrower allow can't override a broader deny.
Syntax: Bash(npm run test *) for a prefix, Read(./.env) for a path, WebFetch(domain:x), mcp__server__*, Agent(Explore).
Modes: default, acceptEdits, plan, auto, dontAsk, bypassPermissions; set a default with defaultMode.
dontAsk with an allow list suits unattended CI; bypassPermissions only in isolated containers or VMs.
permissions.disableBypassPermissionsMode: "disable" in managed settings locks bypass mode off.

Allow Read broadly and deny the sensitive paths. Because deny is checked first, the .env and secrets rules hold even though Read is allowed.

Thinking a more specific allow rule beats a broader deny rule. Deny is always evaluated first.
Using bypassPermissions on a developer laptop or a CI runner with real credentials.
Assuming an unmatched action is allowed; it prompts (or is denied in dontAsk).
Confusing acceptEdits (auto-accepts file edits) with skipping all permission checks.