/restart fails when the CLI was launched with --new-session-id #5147

What happened

Launching the CLI with --new-session-id <uuid> and then running /restart fails every time:

error: the argument '--new-session-id <id>' cannot be used with '--session-id <id>'

Usage: copilot --log-dir <directory> --plugin-dir <directory> --add-dir <directory> --additional-mcp-config <json> --yolo

For more information, try '--help'.

By the time this surfaces the foreground session has already been shut down, so the restart is not recoverable.

Repro

1. copilot --new-session-id 11111111-2222-4333-8444-555555555555 (any fresh UUID)
2. Run /restart

This matters for embedding hosts, which pass --new-session-id on every session launch, so /restart is permanently unusable there rather than occasionally.

Cause

/restart rebuilds the child argv from process.argv.slice(2), strips the session-selection flags, then appends --session-id <current session id>.

In cli-main.js (1.0.98) the strip helper removes -r, --resume, --resume=, --session-id, --session-id=, --continue, --cloud, -i, --interactive, --interactive=, --experimental, --no-experimental, --fleet and -C. --new-session-id is absent from that list, so it survives into the restart argv next to the freshly appended --session-id, and the parser declares the two mutually exclusive.

The same rebuilt argv is persisted for the supervised restart path, so both the supervised and unsupervised paths fail identically.

Expected

The strip helper should drop --new-session-id and --new-session-id=<uuid>, consuming the following value in the bare form, exactly as it already does for --session-id. The session exists by restart time, so re-asserting a creation ID is both wrong and rejected.

Workaround

Patching the strip helper locally to treat --new-session-id like --session-id resolves it, but the file lives in the extracted package folder and the fix is lost on every CLI update.

Version

1.0.98 on Windows, win32-x64.