[BUG] Multi-line script in a quoted argument is misclassified as multiple commands, defeating auto-approval

[awschmeder]

Problem

A single command that wraps a multi-line script in a quoted argument (e.g. sh -c '...' with a real line break inside the quotes) is misclassified as a multi-statement sequence. The embedded newline is treated as a command separator before quote handling, so the quoted script is shredded into bogus sub-commands. This defeats allowlist auto-approval (the wrapper prompts the user even when allowlisted) and produces a noisy command-pattern breakdown in the UI.

Context

Affects anyone whose agent runs a wrapper command (sh -c, bash -c, python3 -c, etc.) with a multi-line script passed as a single quoted argument. Even when the wrapper prefix is on the auto-approval allowlist, the command falls through to a manual approval prompt, adding friction to otherwise-approved workflows. This maps to the Reliability First roadmap goal (consistently reliable command execution).

Reproduction steps

1. Add sh to the command auto-approval allowlist.
2. Ask the coding agent to run a wrapper command whose quoted argument contains an actual line break between statements, e.g.:

   sh -c 'echo 1;
   echo 2'
   

   (note the real newline inside the single-quoted argument)
3. Observe the identified command components and the resulting auto-approval decision.

Expected result

The quoted argument stays intact, so the identified commands are:

sh -c 'echo 1; echo 2'
sh

and the command auto-approves because sh is allowlisted.

Actual result

The embedded newline splits the command before quoting is handled, yielding bogus components:

sh -c echo 1   (incorrect: "echo 1" is a partial fragment of the quoted string)
echo 2         (incorrect: "echo 2" is a string argument, not a separate command)
sh

Those fragments match neither the allowlist nor the denylist, so getCommandDecision falls through to ask_user even though sh is allowlisted. The UI also surfaces the stray script-line fragments as separate command patterns.

Variations tried

The same misclassification occurs whenever a newline is embedded in the quoted argument, across all quote styles:

• Single-quoted multi-line argument (sh -c '...\n...')
• Double-quoted multi-line argument (sh -c "...\n...")
• ANSI-C quoted multi-line argument (sh -c $'...\n...'), which additionally leaks an internal placeholder token into the output.

Genuine unquoted multi-statement scripts (newlines outside any quotes) correctly split into separate sub-commands -- that behavior is expected and should be preserved.

App Version

v3.56.0