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

### 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//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..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\\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.

Start with the orphaned tool-call records in ~/.copilot/session-state//workspace.yaml and events.jsonl, then inspect the Windows crash dumps under %LOCALAPPDATA%\CrashDumps and the runtime.node failures. Compare crashes during session replay, compaction, and in-flight network requests across the reported versions. Done means the crash mechanism is reproduced and the CLI no longer repeatedly crashes during these flows.

Written by the indexing model from the issue text.