Bash permission heuristic misparses shell command boundaries (escaped semicolons treated as separators)
Bug
The Bash permission heuristic incorrectly parses the escaped semicolon (\;) in find -exec as a shell command separator, causing it to treat the remainder of the command (the 2 in 2>/dev/null) as a separate command.
Reproduction
Run this command in Claude Code:
find /Users/MyUser/some/directory -name "*.js" -exec grep -l "generateSitemaps" {} \; 2>/dev/null | head -5The permission prompt appears, but says:
Yes, and don't ask again for: 2
This confirms the heuristic split the command at \; and classified 2 (from 2>/dev/null) as a standalone command.
Expected Behavior
\; is the standard find -exec terminator — it's not a shell command separator. The heuristic should recognize this extremely common pattern and not split the command at this point.
Impact
Immediate: False positive
This is a read-only, safe command being flagged unnecessarily.
Deeper concern: Heuristic quality signal
The fact that find -exec {} \; — one of the most common shell patterns in existence — triggers a false positive suggests the semicolon-detection heuristic lacks basic test coverage for escaped/quoted semicolons. If the heuristic doesn't handle this well-known case, it likely has gaps in more nuanced cases too.
Security UX: Warning fatigue
This contributes to the broader problem of permission prompt fatigue. Research on Windows UAC and browser security dialogs has consistently shown that excessive false-positive prompts train users to click "Allow" reflexively, reducing the effectiveness of legitimate warnings. Each false positive erodes trust in the security system.
Related issues with similar false-positive patterns:
- #28183 (compound commands of individually-allowed commands)
- #30892 (
echo "---"flagged as quoted flag characters) - #27957 (request to disable quoted-characters-in-flag-names warning)
- #16449 (quoted hyphen-prefixed values misidentified as flags)
Environment
- macOS
- Claude Code (latest at time of filing)
6 Comments
Found 2 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
Security concern: command boundary misparsing cuts both ways
The false positive here is the visible symptom, but the underlying problem is more serious: the heuristic is incorrectly identifying where one command ends and another begins.
In this case, it splits a single safe command into two "commands" and flags the harmless fragment. That's annoying but safe. The dangerous direction is the inverse: if the parser doesn't correctly identify command boundaries, it could also fail to split actually-separate commands, treating a compound command as a single command and inheriting the safety classification of the first half.
Consider a hypothetical where the heuristic incorrectly joins two commands that should be evaluated independently. If the first command matches an allow-list entry, the entire compound command could be auto-approved — including a second command that should have been flagged.
The
find -exec \;case proves the boundary detection is doing naive string matching rather than proper shell parsing. That same naivety could produce false negatives (missed splits) just as easily as it produces false positives (spurious splits). False positives are annoying; false negatives are exploitable.This is worth investigating beyond just fixing the
\;case — the question is whether the heuristic has a principled model of shell command boundaries, or whether it's pattern-matching on;,&&,||,|etc. without understanding quoting, escaping, and subshell contexts.#37391 and #39655 are instances of the problem I'm filing. But they're very targeted at the specific flavor of this particular instance.
The bug report I'm filing is wider pattern of "Command Boundary mis-parsing could lead to false-negatives".
Subsequent commands might be treated as safe because the loose command fragments might change how their escape sequences are interpreted.
Thanks for the detailed report. This is fixed in v2.1.89 (released 2026-03-31).
Root cause: in v2.1.85/86 the permission checker still used the legacy
shell-quoteparser, which treated\;as the operator;rather than a literal argument. After redirect/operator stripping the bare2from2>/dev/nullsurvived as its own "subcommand", which is where the nonsensical "don't ask again for: 2" suggestion came from.v2.1.89 replaced the shell-quote splitter with a real grammar parser. On current main,
find ... -exec ... \; 2>/dev/null | head -5parses to exactly two subcommands (find ...andhead -5) with;correctly inside argv — no spurious2.The related "backslash before shell operator" false-positive warnings (#37391, #39655) were the same root cause and are also fixed in v2.1.89. Please upgrade and reopen if you still see it.
This issue was fixed as of version 2.1.89.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.