Copilot CLI crashes repeatedly (native runtime), reproducible across versions, unresolved since May 2026 #4026

Activity

1. millshre5

   added the

   Bug

   issue type on Jul 4, 2026
2. millshre5

   added

   triage

   on Jul 4, 2026
3. copilot-cli-release-app

   added

   area:platform-windowsWindows-specific: PowerShell, cmd, Git Bash, WSL, Windows TerminalWindows-specific: PowerShell, cmd, Git Bash, WSL, Windows Terminal

   area:sessionsSession management, resume, history, session picker, and session stateSession management, resume, history, session picker, and session state

   and removed

   triage

   on Jul 4, 2026
4. randsu commented on Aug 4, 2026

   

   randsu

   on Aug 4, 2026

   More actions

   Adding a data point from Windows 11 / CLI 1.0.78, in case the signature is useful.

   The crash here is consistently preceded by bridge-ack timeouts from the native runtime, and the fatal one landed in the same second as a subagent launch:

   12:49:14.535Z [WARNING] [rust:copilot_runtime::interop::bridge_backed_seam] timed out waiting for bridge event ack {"event_kind":"event","timeout_ms":30000}
   12:51:54.590Z [INFO]    Completing 1 orphaned tool calls.
   12:53:59.317Z [WARNING] [rust:copilot_runtime::interop::bridge_backed_seam] timed out waiting for bridge event ack {"event_kind":"event","timeout_ms":30000}
   12:53:59.553Z [INFO]    SessionAgentExecutor.execute() called for "rubber-duck" (toolCallId=…)
   12:54:03.747Z [INFO]    --- End of group ---
                           <process gone>
   

   Fourteen bridge_backed_seam … timed out waiting for bridge event ack warnings occurred in that single session across one day, at a 30 s timeout each. The Completing N orphaned tool calls line appearing ~2 minutes before the fatal exit matches the orphaned-call replay loop described in this issue — the session was already carrying orphans when it died.

   If the bridge ack timeout is on the path to the native fault, it may be a more tractable signal to instrument than the crash itself, since it is logged at WARNING well before the process goes down. Possibly related to #2543, given the subagent correlation.

   One caution worth adding for anyone applying the workaround in this thread: renaming ~/.copilot/session-state/<uuid>/ to break the crash loop also discards that session's plan.md, which lives in the same directory. Copy it out first.

   Environment: Windows 11 Enterprise build 10.0.26200, x86_64, Windows Terminal, PowerShell 7.6.4, Node v24.18.1, autoUpdate: false, mouse: false.
5. randsu commented on Aug 5, 2026

   

   randsu

   on Aug 5, 2026

   More actions

   Correcting my earlier comment — I over-weighted the bridge-ack timeouts. A second crash today lets me isolate the trigger, and it is much more specific.

   Across all my session logs, correlating every SessionAgentExecutor.execute() against when the log stops:

   Subagent	Launched	Log ends	Session lifetime after launch
   github-context-memory	13:31:14	14:02:26	survived 31 min
   task	13:32:01	14:02:26	survived 30 min
   rubber-duck	12:53:59	12:54:03	died in 4.2 s
   rubber-duck	13:14:29	13:14:30	died in 1.3 s

   Both rubber-duck launches killed the process within seconds. Two other subagent types ran in the same environment and the session stayed up for half an hour.

   Critically, the second crash had no bridge_backed_seam ack timeouts at all — its log contains only two startup GitHub MCP server configured after authentication errors, then the rubber-duck launch, then the process is gone 1.35 s later. So the bridge timeouts in my first comment were incidental to that session rather than on the crash path. Apologies for the noise.

   The confound is now resolved with a full matrix on the same machine and CLI version (subagent model pinned via subagents.agents.rubber-duck in settings):

   Session model	Subagent model	Result
   claude-opus-5	gpt-5.6-sol (cross-family override)	crash in 1.3–4.2 s (2/2)
   claude-opus-5	claude-opus-5 (inherit)	clean, 5m35s to completion
   gpt-5.6-sol	gpt-5.6-sol (inherit)	clean, 33s to completion

   So the trigger is specifically a subagent carrying a cross-family model override — not the rubber-duck agent type, not the session's model family, and not subagent execution per se. The crash is in whatever path handles non-session-family model selection for subagent execution. inherit is a complete workaround in both directions.

   Given the subagent correlation this may belong with #2543 rather than here — happy for it to be moved.

   Environment: Windows 11 Enterprise build 10.0.26200, x86_64, Windows Terminal, PowerShell 7.6.4, Node v24.18.1, CLI 1.0.78, autoUpdate: false, mouse: false.
6. randsu commented on Sep 11, 2026

   

   randsu

   on Sep 11, 2026

   More actions

   Two data points for the parent thread, following up on my August crash matrix.

   1. The native fault site did not move between releases. From the Windows Error Reporting records of the crashes I reported on Aug 3 and Aug 5: the fault offset 0x0000000002224369 and the module timestamp are identical on copilot.exe 1.0.77.0 and 1.0.78.0, two shipped builds two days apart. That points at a shared native component rather than the JS bundle. (GitHub Support, who have the sanitized WER records and process logs from my ticket, noted the same and asked me to quote it here.)

   2. Retest on 1.0.83: neither of my isolated triggers reproduces any more. Windows 11 Enterprise 10.0.26200, x64, Windows Terminal, interactive sessions driven through a scripted ConPTY so the timing is exact:

   • Cross-family subagent model override (subagents.agents.<name>.model): session claude-opus-5 with the subagent overridden to gpt-5.6-sol, twice; the reverse direction; claude-fable-5.1 -> gpt-6-astra; the same with experimental features on; and two cross-family subagents launched in parallel 3 ms apart. 6/6 clean. On 1.0.78 the identical override fail-fasted (0xc0000409) within 1.3-4.2 s, 2/2. subagent.configured in the session log confirms the override was applied in every run.
   • Mid-turn interactive -> autopilot switch with allow-all just enabled (my second trigger, distinct hashed bucket): /allow-all then /autopilot typed while a long turn was in flight, three times; /autopilot first (the CLI enables allow-all itself 0.36 s before the mode change, exactly the pair in my Aug 6 log); and autopilot -> interactive mid-turn. 5/5 clean, every session kept working for minutes afterwards.

   Side observation: /rubber-duck, the command that carried the August subagent crashes, is no longer registered in 1.0.83 on this account (Unknown command, in both Claude and GPT sessions, although copilot help commands still lists it), and rubber-duck is absent from the task tool's agent list. If that path was removed or gated on purpose it may be the actual fix for the subagent trigger.

   No copilot.exe crash record on this machine since Aug 6, across daily use of 1.0.82 and 1.0.83 since Sep 3.
7. patniko commented on Oct 26, 2026

   

   patniko

   on Oct 26, 2026

   Collaborator

   More actions

   Thanks for the report. We've shipped fixes in this area since this was filed, and we believe this may now be resolved. Could you retest on the latest release (Copilot CLI v1.0.103) and let us know whether you still see it? If we don't hear back in a couple of weeks, we may close this issue — you can always reopen it.

   _{Triaged as part of a Copilot SDK backlog review, with help from GitHub Copilot.}
8. patniko

   added

   more-info-needed

   on Oct 26, 2026
9. randsu commented on Oct 27, 2026

   

   randsu

   on Oct 27, 2026

   More actions

   @patniko Following up on the Sep 11 retest, which was already on 1.0.83 and came back clean for both of my isolated triggers (cross-family subagent model override and mid-turn interactive to autopilot switch with allow-all).

   Since then I have used the CLI daily on Windows 11 Enterprise 10.0.26300, x64, through 1.0.93 and now 1.0.104, 42 interactive sessions since Sep 11 and 30 in October.

   There is no copilot.exe crash record in Windows Error Reporting on my machine since Aug 6 and no minidump since then.

   The only WER entries for copilot.exe in the last 60 days are two RADAR_PRE_LEAK_64 memory-leak reports on 1.0.83 and 1.0.93, not crashes.

   From my side the native crash family reported here is resolved and I have no objection to closing 👍