{"version":"2.1.309","anchor":"shell-parser-ansi-c-strings-and-escaped-newlines-now","canonical_anchor":"shell-parser-ansi-c-strings-and-escaped-newlines-now","heading":"More commands with unusual shell quoting are treated as unreadable","tier":"notice","area":"Bash Safety","scope":"individual","heads_up":true,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.309\/e\/shell-parser-ansi-c-strings-and-escaped-newlines-now","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.309","markdown":"### More commands with unusual shell quoting are treated as unreadable\n\nClaude Code now marks more commands with `$'...'` strings, escaped line breaks or odd `$[` and `${` forms as ones it could not parse\n\n**Unclear.** Whether a command that cannot be parsed always leads to a permission prompt is not confirmed.\n\n**What**\n\nBefore running a shell command, Claude Code reads its structure to check it against your permission rules. It now marks a command as one it could not parse when it contains any of these:\n\n- a `$` or a backtick inside a double-quoted part of a string, including inside an ANSI-C string written as `$'...'`\n\n- a backslash followed by a line break inside an expansion\n\n- `$[`\n\n- `${` followed by a space or `|`\n\nBefore, `$'...'` strings were scanned without this check for nested expansions. Claude Code also now recognises a list of read-only shell variable names, such as `BASHPID` and `BASH_SOURCE`.\n\n**Why**\n\nCommands written with this kind of quoting now land in the could-not-parse case, which is where Claude Code tends to ask for permission rather than rely on a rule.\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"}