Claude Code Permission Rules (allow/ask/deny) and settings.json Guide
Claude Code's permission rules let you write allow/ask/deny entries in settings.json to specify, fine-grained, which tools, commands, files, and domains run without asking, prompt every time, or are forbidden. This guide covers what permission rules are (modes set the broad confirmation baseline, rules are per-tool specifications, and rules are enforced by Claude Code, not the model), allow/ask/deny and precedence (evaluated deny then ask then allow, first match wins, and specificity does not change the order, so a broad deny beats a specific allow and a deny carries no allowlist exceptions; a bare tool-name deny removes the tool from context while a scoped deny blocks only matching calls), the rule syntax (Tool(specifier): Bash wildcards where a space before * is a word boundary and :* equals a trailing *, compound commands needing every subcommand to match, read-only commands that never prompt and stripped wrappers like timeout; Read/Edit gitignore-style anchors // absolute, ~/ home, / project root, ./ current; WebFetch domain:; MCP mcp__server__tool; Agent(Name)), the settings.json hierarchy and precedence (managed > CLI > .claude/settings.local.json > .claude/settings.json > ~/.claude/settings.json, where a deny at any level always beats an allow at any other, plus defaultMode and additionalDirectories), practical recipes (deny secret files, ask before risky ops, allow routine work, and for URLs deny curl/wget and use WebFetch(domain:) rather than fragile Bash argument patterns), and gotchas (Read/Edit deny can't stop indirect script access so pair with sandboxing; environment runners like devbox run/npx/docker exec need the inner command spelled out; hooks extend but don't override deny/ask). Based on the official docs as of June 2026.