splitCompoundCommandSegments splits on an operator inside a trailing # comment #11815

What happened?

splitCompoundCommandSegments does not model # comments, so an operator sitting inside a trailing comment is read as real command structure and the line is split where bash does not split it. The permission decision then asks for confirmation on a command an allow rule already covers.

For echo 'a' # comment ; echo B, bash runs a single command — the comment swallows everything from # to the end of the line. The splitter returns two segments, echo 'a' # comment and echo B, so a user who has allowed Bash(echo *) still gets a prompt.

The direction is fail-closed: the extra segment can only add a rule that must pass, never remove one, so no verdict is weakened. It is a usability defect rather than a security one.

Steps to reproduce

Allow only echo in settings.json:

{
  "permissions": {
    "allow": ["Bash(echo *)"]
  }
}

Then have the model run echo 'a' # comment ; echo B. The call stops for confirmation even though bash runs one echo, which the rule covers.

That bash runs one command is plain from bash itself:

$ bash -xc "echo 'a' # comment ; echo B"
+ echo a
a

Measured shapes

split is what splitCompoundCommand returns; bash is what the shell actually runs.

The last two are why this is not a one-line change. git status # don't ; echo B happens to come out right only because the apostrophe in don't opens a quote that masks the ;, and echo a#b is correctly left alone because # is only a comment at the start of a word.

What did you expect to happen?

A line that bash runs as one command should be one segment, so an allow rule that covers that command applies without a prompt.

Client information

Version: 0.23.3
OS: macOS 26.5.2 (arm64)
Node: v22.22.1
Shell: GNU bash 3.2.57(1)-release

Login information

Not relevant — the defect is in permission rule splitting and does not involve the model provider or authentication.

Anything else we need to know?

Filed as the follow-up agreed in review on #11765, which fixes a different defect in the same scanner: a backslash inside a plain '…' string was read as an escape, which swallowed the closing quote and glued a whole line into one segment.

Two of the rows above predate that PR and two are widened by it, and the distinction matters for whoever picks this up:

• echo 'a' # comment ; echo B over-splits on main today, unchanged by fix(core): read a backslash inside single quotes as literal when splitting #11765.
• echo 'a\' # … ; … does not over-split on main, but only by accident — the old scanner was still stuck inside an unterminated quote, which masked the comment. Once the quote correctly closes, the ; inside the comment becomes visible and the line splits.

So #11765 widens an existing gap rather than creating one, and narrowing its quote handling to avoid these shapes would re-open the bypass it closes, since the two are the same shape. Comment handling has to be added deliberately instead, and needs to cover at least:

• # starts a comment only at the start of a word — echo a#b is not a comment.
• # inside a quoted string is literal.
• Heredoc bodies, where # is ordinary text.
• The interaction with the line-continuation handling, since a comment runs to the end of the logical line.

A regression test for each row in the table above would pin the behaviour either way.