{"version":"2.1.319","anchor":"bash-permission-command-matching-gets-normalised","canonical_anchor":"bash-permission-command-matching-gets-normalised","heading":"Command permission rules are matched in a different way","tier":"notice","area":"Permissions","scope":"both","heads_up":true,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.319\/e\/bash-permission-command-matching-gets-normalised","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.319","markdown":"### Command permission rules are matched in a different way\n\nAllow, deny and ask rules for shell commands now compare commands through a shared normalising step instead of simple lowercasing\n\n**Unclear.** Which commands are now matched or allowed differently is not known.\n\n**What**\n\nPermission rules decide whether Claude Code may run a shell command without asking. An allow rule lets it run, a deny rule blocks it and an ask rule makes Claude Code ask you first. These rules now compare commands in a new way:\n\n- Commands are tidied into a standard form before they are compared. Before, both sides were only changed to lowercase.\n\n- PowerShell command names go through the same step.\n\n- Allow rules that use wildcards now match only in some situations.\n\n- An ask result can now be overridden in some cases.\n\n**Why**\n\nThis affects which commands run without asking, so it is worth checking that your allow and deny rules still behave as you expect.\n\n- Area: Permissions\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 2\/5\n- Scope: both\n- Heads-up: yes"}