{"version":"2.1.285","anchor":"quieter-permission-check-for-env-var-like-arguments-after-ce","canonical_anchor":"quieter-permission-check-for-env-var-like-arguments-after-ce","heading":"Fewer shell permission refusals for NAME=value arguments after some commands","tier":"notice","area":"Permissions","url":"https:\/\/changelogs.core-directive.com\/v\/2.1.285\/e\/quieter-permission-check-for-env-var-like-arguments-after-ce","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.285","markdown":"### Fewer shell permission refusals for NAME=value arguments after some commands\n\nSome allowed shell commands followed by a NAME=value argument no longer fail the permission check as an unsafe variable setting\n\n**Unclear.** Which commands this covers and which names the pattern accepts are not known.\n\n**What**\n\nBefore Claude Code runs a shell command, it checks whether the command is safe to run without asking you. One thing it looks for is text of the form `NAME=value`, which can set an environment variable. Environment variables are named settings that programs read. Before, any `NAME=value` whose name was not on a known-safe list made the check fail.\n\nNow a `NAME=value` that comes after the command word of certain allowed commands is no longer treated as an unsafe variable setting, as long as the name fits a set pattern. This sits behind a remote switch, and the code falls back to on when the server sends no value.\n\n**Why**\n\nCommands such as `cmd KEY=val` should lead to fewer permission prompts or fallbacks.\n\n- Flag `tengu_quiet_larkspur`: Not enough to say (read for one account on one subscription tier against v2.1.285; this account: no value returned, anonymous baseline: no value returned, compiled default: on) These values were read against a different version of Claude Code, so treat them as the nearest reading available instead of one taken on this release.\n- Area: Permissions\n- Tier: You'll notice\n- Useful: 2\/5\n- Signal: 2\/5"}