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.

先从 ~/.copilot/session-state//workspace.yaml 和 events.jsonl 中的孤立工具调用记录开始，然后检查 %LOCALAPPDATA%\CrashDumps 下的 Windows 崩溃转储以及 runtime.node 失败。比较报告版本中会话重放、压缩和进行中的网络请求期间发生的崩溃。完成标准是能够复现崩溃机制，并且 CLI 在这些流程中不再反复崩溃。

由索引模型根据 Issue 内容生成。