Your settings contain a rule denying a family of shell commands and, further down, a rule allowing one specific command inside that family. Claude proposes exactly that command. What happens, and why?

The principle — precedence in this system is by category, not by specificity and not by position.

Why the key is correct — Anthropic states the evaluation order in one line: rules are evaluated deny, then ask, then allow, first match wins. Read that as three passes rather than one list. The deny category is consulted first, and the moment something matches there the search stops and the answer is no. The allow rule further down is never reached, so how narrowly it is written and where it sits make no difference to the outcome. This is the behaviour you want from a deny rule: if a more specific allow could quietly reopen it, then no denial would ever be dependable, and an organisation could not rely on one.

Why the others are wrong — specificity winning is the intuition people carry over from CSS and from some firewall configurations, and it is simply a different model from this one. Later-wins is the other common import, from shell configuration and layered config files; here position within a category does not decide anything, because the categories are ordered before the entries are. And the mode does not arbitrate: Anthropic is explicit that modes set the baseline and permission rules layer on top to pre-approve or block specific tools, so your rules remain in force whatever mode is selected.

Remember this — a deny rule is the strongest thing you can write. Nothing further down the file loosens it.

Sources — Anthropic's Claude Code glossary and the permission modes page.