[Bug] --resume silently exits with 'no supported shell detected' on Windows, never opens interactive session

[docrinehart]

Describe the bug

When using \copilot --resume=\ (or --resume=) on Windows, the CLI process starts and immediately exits silently without opening an interactive session and without printing any error to the terminal. The only evidence of failure is a tiny log file containing a single line.

Error message

No output shown to the user. Log file (89 bytes) contains only:

\
2026-05-21T18:00:46.114Z [INFO] Shell completions: no supported shell detected, skipping
\\

The process exits immediately after this line. Two separate resume attempts produced identical 89-byte log files — no session was loaded, no prompt appeared.

Affected version

• GitHub Copilot CLI 1.0.51 (Windows, installed via WinGet)
• OS: Windows 11
• Terminal: PowerShell 7 (pwsh)

Steps to reproduce

1. Exit a named session with /exit\ — CLI prints the resume hint, e.g. \copilot --resume="2026-05-21.1336"\
2. Run the printed command in a new terminal: \copilot --resume="2026-05-21.1336"\
3. Also attempted: \copilot --resume=, \copilot --continue\
4. In all cases: process exits immediately, terminal returns to prompt, no interactive session opens

Expected behavior

The interactive session resumes and the Copilot prompt appears.

Actual behavior

The CLI exits silently. No error shown to user. Log shows only the shell completion detection line before process termination.

Additional context

• The session itself was valid and loadable — successfully resumed via the in-app /resume\ command from a separate running session
• The --resume\ flag appears to exit before MCP servers are even initialized (contrast with successful resume logs which show MCP startup entries)
• Shell completion detection failing should be a non-fatal warning, not a reason to exit — especially when --resume\ is explicitly passed

[crahrig]

I asked GHCP if there were similar issues to what I ran into today and it found this issue. Adding a comment here since it seems related instead of a new issue. Pasting the details gathered by GHCP below.

---

Seeing a closely-related-but-distinct symptom on CLI 1.0.52 (Windows 11, pwsh 7.6.1) that I suspect is the same underlying regression in the --resume arg-handling code path.

Symptom (1.0.52)

copilot --resume="<name with spaces>" in an interactive cold-start tab does not match the named session. Instead, the CLI opens normally but silently falls back to "continue most-recent" semantics — picking whatever session was last touched globally, ignoring the requested name.

So unlike #3458's silent-exit symptom on 1.0.51, on 1.0.52 the process does open an interactive session — it just resumes the wrong one with no error or hint that the name didn't match.

Repro

1. Have at least two recent sessions in the store, one of which is the named target. e.g.:
   • "My Named Session" (the one you want to resume)
   • any other recent unrelated session that's more recently updated
2. Launch a fresh pwsh 7 tab with the canonical resume commandline:

   pwsh.exe -NoLogo -NoExit -Command "copilot --resume=""My Named Session"""
   

3. Watch ~/.copilot/session-store.db sessions.updated_at for the named session — it does not get touched. The unrelated most-recent session's updated_at advances instead, confirming Copilot resumed it.

Also reproduces with the space-separated form (copilot --resume "My Named Session").

Argv arrives intact

I verified PowerShell delivers the argument correctly as a single argv token by tracing both a PowerShell child and a Node child:

args[0] = [--resume=My Named Session]   # single token, spaces preserved

So the parsing failure is happening inside Copilot CLI's option parser, not in shell quoting.

What does work on 1.0.52

• Non-interactive print mode resumes by name correctly: copilot --resume="My Named Session" -p "..." (confirmed via cached-token hit on the resumed session)
• Interactive resume by full session UUID: copilot --resume=<uuid> works reliably (this is my current workaround for Windows Terminal profile commandlines that need zero-keystroke resume)

The fact that non-interactive name-based resume works while interactive name-based resume silently picks the wrong session strongly suggests two different code paths handle --resume value parsing, and the interactive path has the regression.

Workaround

If you also need resume to work reliably across CLI restarts, switch your launcher commandline from --resume="<name>" to --resume=<uuid>. Names containing spaces appear to be the trigger (or at least the most reliable repro); haven't tested whether single-token names with no whitespace also fail in interactive mode.

Happy to break this out into a separate issue if maintainers prefer — leaving it here in case it's helpful diagnostic context for #3458 since both regressed in the same release window.