{"version":"2.1.310","anchor":"env-var-prefix-stripping-in-permission-matching-now-consider","canonical_anchor":"env-var-prefix-stripping-in-permission-matching-now-consider","heading":"Bash permission checks now look at the value of leading environment variables","tier":"notice","area":"Permissions","scope":"individual","heads_up":true,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.310\/e\/env-var-prefix-stripping-in-permission-matching-now-consider","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.310","markdown":"### Bash permission checks now look at the value of leading environment variables\n\nWhen a Bash command starts with VAR=value, permission matching now checks the value as well as the variable name\n\n**Unclear.** It is not clear which values are now accepted or refused, so it is unclear whether commands that used to match a rule might now ask for permission.\n\n**What**\n\nA Bash command can start by setting an environment variable (a named setting passed to a program), as in `VAR=value command`. When Claude Code compares such a command against your permission rules, it decides whether that leading prefix can be safely set aside. Before, it decided by checking only the variable's name against a list of allowed names. It now takes both the name and the value into account.\n\n**Why**\n\nThis makes Claude Code stricter about which variable prefixes it treats as safe when matching Bash permission rules.\n\n- Area: Permissions\n- Tier: You'll notice\n- Useful: 1\/5\n- Signal: 1\/5\n- Scope: individual\n- Heads-up: yes"}