PRODUCTION SCENARIO
Your team's committed .claude/settings.json denies Bash(aws *). A developer adds Bash(aws s3 ls *) to their own .claude/settings.local.json so they can pull bucket inventories. Claude Code still blocks the command, and the denial names the team's rule. The command Claude proposes is a plain aws s3 ls, run on its own with no variable assignment in front of it and not joined to any other command, and the team's rule names a pattern rather than the bare Bash tool.
Which rule of the permission system explains the block?
Answering here is anonymous. Nothing is saved unless you sign in.
Show answer and explanation
Answer: Deny is evaluated before allow, and specificity does not change that order
Rules are evaluated deny, then ask, then allow, and a narrower allow cannot carve an exception out of a broad deny, so Bash(aws *) blocks a call that Bash(aws s3 ls *) also matches; the fix is to narrow the deny to the subcommands that must stay blocked. The assignment rule is what explains the block when the command runs as PROFILE=prod aws s3 ls, and nothing is assigned here. The subcommand rule explains it when the call sits inside a compound command or a loop body, and this one stands alone. Bare-name removal applies when the deny is written as Bash with no pattern, and this deny is scoped.
Official Source: https://code.claude.com/docs/en/permissions ↗