{"version":"2.1.315","anchor":"shell-parsing-treats-path-like-values-as-possibly-in-the-wor","canonical_anchor":"shell-parsing-treats-path-like-values-as-possibly-in-the-wor","heading":"Shell commands whose variables may point at a file in the working directory are now flagged","tier":"notice","area":"Bash Safety","scope":"individual","heads_up":true,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.315\/e\/shell-parsing-treats-path-like-values-as-possibly-in-the-wor","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.315","markdown":"### Shell commands whose variables may point at a file in the working directory are now flagged\n\nClaude Code now flags commands where a variable set to a relative value may name a file in the working directory\n\n**What**\n\nBefore running a shell command, Claude Code checks it for risky patterns. Until now these checks flagged only paths written out literally that were relative or inside the working directory, which is the folder Claude Code is working in. They now also flag values that could name a file in that folder. One example is a variable set to a relative value. Another is a relative path that follows a variable.\n\nThe extra check covers:\n\n- environment variable assignments at the start of a command\n\n- `git -c` options\n\n- the `--shell` option of `su` and `runuser`\n\nA command flagged this way gives the reason \"which may name a file in the working directory\".\n\n**Why**\n\nSome commands that build a path from a variable were allowed before. They may now stop and ask for your permission, or be held back.\n\n- Area: Bash Safety\n- Tier: You'll notice\n- Useful: 1\/5\n- Signal: 1\/5\n- Scope: individual\n- Heads-up: yes"}