{"version":"2.1.277","anchor":"env-var-prefix-stripping-in-shell-command-normalization-now","canonical_anchor":"env-var-prefix-stripping-in-shell-command-normalization-now","heading":"Env-var-prefix stripping in shell-command normalization now conditional","tier":"internal","area":"Bash Safety","scope":null,"heads_up":null,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.277\/e\/env-var-prefix-stripping-in-shell-command-normalization-now","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.277","markdown":"### Env-var-prefix stripping in shell-command normalization now conditional\n\nShell-command normalization can now skip stripping VAR=value prefixes when matching permission rules\n\n**Unclear.** The finding does not say which call sites pass false or what practical difference this makes for a user writing permission rules.\n\n**What**\n\nWhen Claude Code checks a shell command against permission rules, it first normalizes the command text by stripping leading `VAR=value` environment-variable assignments and shell wrapper keywords like `builtin` or `noglob`. That stripping step is now controlled by a new boolean parameter, `n`, which defaults to true. Several existing call sites already pass false, meaning they skip the `VAR=value` stripping and match against the command text as written.\n\n**Why**\n\nThis lets some permission checks see the full original command, including any environment-variable prefix, instead of always having that prefix stripped away first. That can affect whether a permission rule matches a command that starts with a variable assignment.\n\n- Area: Bash Safety\n- Tier: Under the hood\n- Useful: 2\/5\n- Signal: 2\/5"}