{"version":"2.1.321","anchor":"explicit-allow-rule-normalisation-reworked","canonical_anchor":"explicit-allow-rule-normalisation-reworked","heading":"Permission rules ending in (*) or () are matched differently","tier":"notice","area":"Permissions","scope":"individual","heads_up":true,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.321\/e\/explicit-allow-rule-normalisation-reworked","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.321","markdown":"### Permission rules ending in `(*)` or `()` are matched differently\n\nRules written as a tool name followed by `(*)` or `()` are read as covering the whole tool, without the earlier allow-only check\n\n**Unclear.** It is unclear whether deny and ask rules written with `(*)` or `()` are now also treated as covering the whole tool.\n\n**What**\n\nPermission rules tell Claude Code which tools it may use without asking. A rule written as a tool name followed by `(*)` or `()` is read as a rule for the whole tool.\n\nBefore, Claude Code read rules this way only when they were allow rules and an extra internal check passed. The code that does this no longer looks at what kind of rule it is or at that extra check.\n\n**Why**\n\nIf you use rules written with `(*)` or `()`, the way they are matched may differ from before.\n\n- Area: Permissions\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 1\/5\n- Scope: individual\n- Heads-up: yes"}