{"version":"2.1.305","anchor":"bash-tokenizer-flags-keyword-desync-as-an-error-node","canonical_anchor":"bash-tokenizer-flags-keyword-desync-as-an-error-node","heading":"Shell command parser handles a keyword after command words differently","tier":"soon","area":"Bash Safety","scope":"individual","heads_up":false,"url":"https:\/\/changelogs.core-directive.com\/v\/2.1.305\/e\/bash-tokenizer-flags-keyword-desync-as-an-error-node","release_url":"https:\/\/changelogs.core-directive.com\/v\/2.1.305","markdown":"### Shell command parser handles a keyword after command words differently\n\nThe parser that checks Bash commands now flags a shell keyword after command words with `keywordAfterPrefix`, and the prefix check splits and tests those commands\n\n**What**\n\nBefore Claude Code runs a shell command, it breaks the command into parts to decide how it should be handled for permissions. This release changes what happens when ordinary command words come before a shell keyword (a reserved word of the shell language).\n\n- Parser: its internal state gains a `keywordDesync` flag. When command words precede a shell keyword and a gate is on, the parser sets that flag and returns an error result marked `keywordAfterPrefix: true`, meaning it treats the command as one it could not cleanly read.\n\n- Prefix check: when `keywordAfterPrefix` is true, the check that compares a command against known command prefixes now splits the text into extra parts and tests each one. A command can count as matching if any of those parts matches. Before, only the command's text and its listed items were tested.\n\n**Why**\n\nThis affects how some shell commands are classified when Claude Code decides whether to ask you before running them. Commands that combine leading words with a shell keyword may be handled differently than before.\n\n- Area: Bash Safety\n- Tier: Nothing to try yet\n- Useful: 1\/5\n- Signal: 2\/5\n- Scope: individual\n- Heads-up: no\n- Present in the build but not switched on"}