{"version":"2.1.282","anchor":"bash-permission-rules-with-in-the-middle-are-no-longer","canonical_anchor":"bash-permission-rules-with-in-the-middle-are-no-longer","heading":"Bash permission rules with :* in the middle no longer fail to load","tier":"notice","area":"Permissions","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.282\/e\/bash-permission-rules-with-in-the-middle-are-no-longer","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.282","markdown":"### Bash permission rules with `:*` in the middle no longer fail to load\n\nBash permission rules like `Bash(foo:*bar)`, with `:*` not at the end, are no longer rejected as invalid\n\n**Unclear.** How a rule with `:*` in the middle is now matched against commands is not established; it may be read as a literal colon followed by a wildcard.\n\n**What**\n\nPermission rules in your settings decide which shell commands Claude may run without asking. A rule such as `Bash(npm run:*)` uses `:*` at the end to match any command that starts with that text.\n\nClaude Code used to reject any Bash rule where `:*` appeared somewhere other than the end, such as `Bash(foo:*bar)`, with the error \"The :* pattern must be at the end\". That check has been removed, so such rules are now accepted.\n\nA rule that is only `:*`, with nothing before it, is still rejected with \"Prefix cannot be empty before :*\".\n\n**Why**\n\nSettings files that used to fail validation because of such a rule now load. Because these rules are no longer checked, it is worth making sure any rule with `:*` in the middle matches the commands you actually intend.\n\n- Area: Permissions\n- Tier: You'll notice\n- Useful: 3\/5\n- Signal: 1\/5"}