{"version":"2.1.323","anchor":"bash-command-safety-locale-env-vars-and-wrapper-handling","canonical_anchor":"bash-command-safety-locale-env-vars-and-wrapper-handling","heading":"Stricter checks for shell commands that set language variables","tier":"notice","area":"Permissions","scope":"individual","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.323\/e\/bash-command-safety-locale-env-vars-and-wrapper-handling","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.323","markdown":"### Stricter checks for shell commands that set language variables\n\nShell commands that set LANG, LANGUAGE or LC_* to unusual values are now treated as not clearly safe, behind a remote switch\n\n**Unclear.** The default of the switch that controls this check is not known.\n\n**What**\n\nBefore running a shell command, Claude Code decides whether it is safe or whether it should ask you. Commands that set the language variables `LANG`, `LANGUAGE` or `LC_*` are now marked as not clearly safe when the value:\n\n- contains an expansion, meaning text the shell fills in when the command runs\n\n- does not look like an ordinary UTF-8 setting\n\nThis check sits behind a remote switch. Claude Code's handling of commands wrapped in `env`, `sudo`, `command` or `doas` has also been reworked.\n\n**Why**\n\nPermission checks for shell commands are stricter, so some commands like these may now ask for your approval.\n\n- Area: Permissions\n- Tier: You'll notice\n- Useful: 1\/5\n- Signal: 1\/5\n- Scope: individual\n- Heads-up: no"}