{"version":"2.1.273","anchor":"new-outright-deny-path-for-permission-rules-on-code-running","canonical_anchor":"new-outright-deny-path-for-permission-rules-on-code-running","heading":"New outright-deny path for permission rules on code-running tools","tier":"notice","area":"Permissions","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.273\/e\/new-outright-deny-path-for-permission-rules-on-code-running","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.273","markdown":"### New outright-deny path for permission rules on code-running tools\n\nPermission rules can now flatly deny tools that run code as another denied tool would\n\n**What**\n\nWhen Claude Code checks whether a tool is allowed to run because it \"runs code as\" another tool would, it previously only checked for a matching \"ask\" permission rule. It now also checks first for a matching \"deny\" rule (not counting rules that come from tool-narrowing). If one is found, the action is flatly refused with the message: \"Permission to use `<tool>` has been denied: it runs code as `<other tool>` does, and a rule denies `<other tool>`.\"\n\n**Why**\n\nPreviously, a rule that denied one tool could be bypassed by using a different tool that runs code the same way, since only \"ask\" rules were checked in that path. Now a deny rule on the underlying capability blocks it outright.\n\n- Area: Permissions\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 1\/5"}