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

[millshre5]

Describe the bug

Summary

GitHub Copilot CLI crashes frequently and unpredictably during normal interactive use (not on any single reproducible action) on Windows. This has been happening continuously since at least 2026-05-24, across at least four versions (v1.0.15, v1.0.52, v1.0.53, v1.0.54 in May, and v1.0.65, v1.0.67, v1.0.68 confirmed again today, 2026-07-03). Downgrading/upgrading versions does not help — the crash offsets are frequently identical across different versions, which strongly suggests the bug lives in a shared native runtime component (Node/V8 embed) that isn't being rebuilt between releases, rather than in app-level JS code.

Frequency / Impact

• 30+ crashes observed in a single ~3.5 hour window today (2026-07-03, 4:26 PM–6:59 PM) during normal interactive use (chat, running shell commands via the CLI's tool-use).
• A prior investigation on 2026-05-24 logged 30+ crashes in a single day as well, with the same recurring fault offsets.
• Crashes happen often enough that the CLI is frequently unusable for any extended session.

Reproducible crash signatures (Application Event Log, Event ID 1000, copilot.exe faulting)

Recurring fault offsets seen on both 2026-05-24 and 2026-07-03, across different versions:

Fault offset	Exception code	Meaning	Seen on
0x016cb792	0x80000003 (BREAKPOINT)	Hard assertion / V8 DCHECK firing	v1.0.15, v1.0.52 (May); v1.0.65, v1.0.67, v1.0.68 (July)
0xa8f440 / 0xa8f43c	0xc0000005 (Access Violation)	Same code path, adjacent offsets	Both May and July, multiple versions
0xdcd04e	0xc0000005 (Access Violation)	Same code path	Both May and July

New signature observed only in the July session (not seen in May):

Fault offset	Exception code	Meaning
0x0000000002224369	0xc0000409 (STATUS_STACK_BUFFER_OVERRUN)	Stack cookie/canary violation — recurred 5+ times in one afternoon

One crash faulted directly in runtime.node (the embedded Node runtime DLL) rather than copilot.exe itself:

Faulting module name: runtime.node, version: 0.0.0.0, time stamp: 0x6a457f2d
Exception code: 0xc0000005
Fault offset: 0x0000000001e211b4

Notably, copilot.exe reports the identical module timestamp 0x6a0e5564 across v1.0.65, v1.0.67, and v1.0.68 — suggesting these releases share an unchanged native runtime binary/build.

Underlying mechanism (from prior investigation)

A detailed investigation on 2026-05-24 (log available on request, ~780 lines) ruled out several external causes before landing on an internal mechanism:

Ruled out:

• ASUS Armoury Crate / IOMap64.sys / Asusgio3 kernel drivers — crashes continued identically after fully disabling all ASUS services/drivers and a clean reboot (first crash occurred <2 minutes after a driver-free boot)
• Windows Defender — no blocks/detections against copilot.exe in Defender logs
• Auto-update specifically — crashes reproduced with COPILOT_AUTO_UPDATE=false set and pinned versions

Confirmed internal mechanism:

1. Copilot CLI resumes the most-recently-updated session for the current working directory, tracked via ~/.copilot/session-state/<uuid>/workspace.yaml.
2. If Copilot crashes mid-tool-execution, the corresponding tool.execution_start event in that session's events.jsonl has no matching tool.execution_complete — an "orphaned" tool call.
3. On restart, Copilot logs Completing N orphaned tool calls and attempts to replay them. This replay path is itself crash-prone and can crash again immediately (same session, same orphaned data).
4. Each crash cycle can add tokens/state without the session ever cleanly compacting, and a separate crash mode was observed specifically when context utilization approaches the ~80% compaction threshold with a session in this state.
5. This produces a self-reinforcing crash loop: crash → orphaned tool call → resume → replay → crash → repeat. One session accumulated 55+ orphaned tool calls and 76+ new session directories were created for a single working directory in one day as a result.

Additionally, a crash mode was observed today where the session log simply ends after assistant.turn_start with no further events — i.e., the crash occurs while a request to the model is in flight / being processed, before any tool call or response is recorded. This looks related to the Promise::MarkAsSilent / MultiIsolatePlatform::DisposeIsolate V8 fatal error also captured in a separate crash (see below), suggesting a promise-handling bug in the async request/response plumbing.

A separate captured crash (full V8 fatal-error text, not just Event Log offset)

#
# Fatal error in , line 0
# unreachable code
#
#FailureMessage Object: 0000006F161FD220
----- Native stack trace -----
 1: node::MultiIsolatePlatform::DisposeIsolate+5341
 2: V8_Fatal+287
 3: v8::Promise::MarkAsSilent+700340
 4: v8::Promise::MarkAsSilent+732099
 5: v8::Promise::MarkAsSilent+653515
 ... (extended v8::Promise::MarkAsSilent chain) ...
17: EVP_MD_CTX_set_update_fn+270399
18: EVP_MD_CTX_set_update_fn+231768
19: EVP_MD_CTX_set_update_fn+229757
20: EVP_MD_CTX_set_update_fn+232476
21: v8::String::Value::~Value+173003

This crash reproduced identically (same relative stack, same symbol offsets from these exported symbols) on both v1.0.68 and v1.0.67, triggered simply by running copilot --version while an update/network check was in flight. The presence of OpenSSL frames (EVP_MD_CTX_set_update_fn) alongside heavy Promise::MarkAsSilent recursion suggests a crash during TLS-related async/promise handling — plausibly the same underlying defect as the mid-turn crashes described above, since both involve promise lifecycle handling around network I/O.

Minidumps available

Windows generated local minidumps for many of today's crashes (%LOCALAPPDATA%\CrashDumps\copilot.exe.<pid>.dmp, ~1.5–3.6 MB each). I have not attached them here since process memory dumps can contain auth tokens / conversation content, but I'm happy to share one or more privately (e.g. via a private support channel) if that would help get symbolized stack traces.

What I've already tried (none resolved it)

• Downgrading across many versions (1.0.15 through 1.0.68) — same offsets recur regardless of version
• Fully disabling/removing ASUS Armoury Crate, ROG Live Service, and related kernel drivers, with clean reboots
• Disabling auto-update (COPILOT_AUTO_UPDATE=false) and pinning the winget package
• Renaming corrupted session-store.db-wal/-shm and individual crashed session-state directories to break active crash loops (works as a temporary unstick, not a fix)

Affected version

1.0.15, 1.0.52, 1.0.53, 1.0.54, 1.0.65, 1.0.67, 1.0.68

Steps to reproduce the behavior

Steps to reproduce

There is no single reliable repro — this happens intermittently during normal interactive use (chat + shell tool calls), roughly every 5–20 minutes of active use in the sessions observed. It is not tied to any specific command, prompt, or working directory.

Expected behavior

Ask

• Is this a known/tracked issue? The recurring identical offsets across releases suggest it should be reproducible on GitHub's end with a debug build or with the attached-on-request minidumps.
• Any guidance on capturing more actionable diagnostics (e.g., a debug/symboled build, or an env var to get full V8 --trace-* output) would be appreciated.

Additional context

Environment

• OS: Windows 11 Home 10.0.26200
• Install method: winget (GitHub.Copilot)
• Install path: C:\Users\<user>\AppData\Local\Microsoft\WinGet\Packages\GitHub.Copilot_Microsoft.Winget.Source_8wekyb3d8bbwe\copilot.exe
• Versions reproduced on: 1.0.15, 1.0.52, 1.0.53, 1.0.54, 1.0.65, 1.0.67, 1.0.68
• Note: copilot.exe's Win32 FileVersion resource does not reliably reflect the running app version — after auto-update, copilot --version reported a newer version than the on-disk FileVersion metadata showed. This makes crash-log "version" fields (including Windows Event Log WER entries) potentially unreliable for pinpointing which build actually crashed.