CLI crashes (unhandled rejection) when a shell command contains a literal ${} — shell-quote parse throws in classifyShellCommand

Summary

The CLI dies with an unhandled promise rejection when it builds the shell-permission prompt for a command whose text contains a literal ${}. shell-quote's parse() throws Bad substitution: ${}, and classifyShellCommand → shellPermissionRulesForCommand → getShellPermissionChoices → ShellPermissionPrompt does not catch it, so the whole session exits.

This is not a "bad command" problem: the command is never run, and the user never sees a prompt. The process is gone, and with it the conversation context of a long-running session.

Environment

Stack trace (as printed)

✖ CRITICAL: Unhandled Promise Rejection!
✖ ERROR → Error
ℹ REASON → Bad substitution: ${}
ℹ ERROR STACK ↓
 Error: Bad substitution: ${}
    at parseEnvVar (/opt/homebrew/lib/node_modules/command-code/node_modules/shell-quote/parse.js:157:12)
    at /opt/homebrew/lib/node_modules/command-code/node_modules/shell-quote/parse.js:236:14
    at Array.map (<anonymous>)
    at parseInternal (/opt/homebrew/lib/node_modules/command-code/node_modules/shell-quote/parse.js:113:17)
    at parse (/opt/homebrew/lib/node_modules/command-code/node_modules/shell-quote/parse.js:309:15)
    at classify (file:///opt/homebrew/lib/node_modules/command-code/dist/cli.mjs:2:382298)
    at classifyShellCommand (file:///opt/homebrew/lib/node_modules/command-code/dist/cli.mjs:2:383445)
    at shellPermissionRulesForCommand (file:///opt/homebrew/lib/node_modules/command-code/dist/cli.mjs:2:1075519)
    at getShellPermissionChoices (file:///opt/homebrew/lib/node_modules/command-code/dist/cli.mjs:2:1083719)
    at ShellPermissionPrompt (file:///opt/homebrew/lib/node_modules/command-code/dist/cli.mjs:16:21387)

ℹ Trace ID: 2bf510fd5bd624f90b2282f692816b84

Minimal repro of the throwing dependency

shell-quote throws on a literal ${} (empty substitution), while every other ${...} form parses fine:

const { parse } = require('shell-quote'); // 1.10.0

parse('echo ${VAR}');          // ok
parse('echo ${#a[@]}');        // ok
parse('echo ${PIPESTATUS[0]}');// ok
parse('echo ${!v}');           // ok
parse('echo $(( 1 + 2 ))');    // ok

parse('echo ${}');             // throws: Bad substitution: ${}
parse('echo "${}"');           // throws: Bad substitution: ${}
parse('printf %s ${}');        // throws: Bad substitution: ${}

Source: shell-quote/parse.js parseEnvVar() throws when ${ is immediately followed by }.

How it happens in practice

The model writes a shell command whose text happens to contain ${} — for example when echoing or heredoc-ing documentation/templates that mention ${} literally, or when a variable name is interpolated into an empty string while composing the command. The CLI then tries to classify that command for the permission prompt and crashes before showing anything.

Expected behaviour

Classification of a command that cannot be parsed should degrade, not kill the process. Something like:

1. wrap the shell-quote parse() call in try/catch inside classify / classifyShellCommand,
2. on a parse error, fall back to the most conservative classification (treat the command as unrecognised and require explicit approval), and
3. surface the parse error in the prompt instead of throwing.

A global unhandledRejection guard around the prompt path would also prevent a single classification bug from ending the session.

Impact

• The CLI exits mid-run. In an orchestrated, multi-session setup the managing session dies and its conversation context is lost; recovery has to be done by hand from the run artifacts.
• Because the crash is in the permission prompt path, --trust / auto-yes settings do not help: the process dies while building the prompt.

Trace classifyShellCommand through shellPermissionRulesForCommand, getShellPermissionChoices, and ShellPermissionPrompt, then reproduce the failure with shell-quote's parse('echo ${}'). Ensure an unparseable command no longer exits the session, uses conservative approval behavior, and surfaces the parse error in the prompt.