{"version":"2.1.246","anchor":"warning-when-a-bash-allow-rule-wildcards-the-subcommand-slot","canonical_anchor":"warning-when-a-bash-allow-rule-wildcards-the-subcommand-slot","heading":"Warning when a Bash allow rule wildcards the subcommand slot","tier":"notice","area":"Permissions","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.246\/e\/warning-when-a-bash-allow-rule-wildcards-the-subcommand-slot","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.246","markdown":"### Warning when a Bash allow rule wildcards the subcommand slot\n\nAdding an allow rule like Bash(git *) now warns the wildcard also auto-approves dangerous options.\n\n**What**\n\nAdding an allow rule such as `Bash(git *)` now warns that the wildcard also matches options placed at that position and approves them without prompting, and suggests putting the `*` after the subcommand instead. git is called out because options like `-c` and `--exec-path` can run arbitrary commands.\n\n**Details**\n\n- This is a warning only. The rule is still accepted and saved.\n- It fires during allow-rule validation, on the allow path only.\n\n**Evidence**\n\n`For git, options such as -c and --exec-path can run arbitrary commands.`\n\n- Area: Permissions\n- Tier: You'll notice\n- Useful: 4\/5\n- Signal: 3\/5"}