{"version":"2.1.269","anchor":"managed-settings-denyask-rules-starting-with-are-now-re","canonical_anchor":"managed-settings-denyask-rules-starting-with-are-now-re","heading":"Managed-settings deny\/ask rules starting with '!' are now rejected with a warning","tier":"notice","area":"Permissions","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.269\/e\/managed-settings-denyask-rules-starting-with-are-now-re","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.269","markdown":"### Managed-settings deny\/ask rules starting with '!' are now rejected with a warning\n\nManaged-settings deny\/ask rules starting with '!' are now dropped with a warning instead of applied\n\n**What**\n\nWhen Claude Code applies managed settings inherited from a parent process, deny or ask permission rules written like `Read(...!` or `Edit(...!` (an exception-style negation) are now filtered out, and a warning is logged explaining why. These rules only work to strip paths from earlier rules in a list, so when merged directly into policy they don't restrict anything.\n\n**Why**\n\nWithout this change, such a rule could look like it was denying or restricting something when it actually had no effect once merged, creating a false sense of restriction. The warning tells users to write the deny rule without the exception syntax instead.\n\n- Area: Permissions\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 2\/5"}