Describe the bug
Summary
copilot.exe crashes with an access violation (0xc0000005) inside the native Windows addon win_error_mode.node shipped with v1.0.22-0. The crash is reproducible and consistent. The same-size file from v1.0.21 is stable — v1.0.22-0 shipped a broken build of this native addon.
Environment
| Field |
Value |
| OS |
Windows 11, x64 |
| Copilot CLI version (WinGet) |
v1.0.18 |
| Active pkg cache version |
v1.0.22-0 (launcher always selects the highest semver) |
| Shell |
Windows Terminal |
Steps to Reproduce
- Install GitHub Copilot CLI via WinGet (any version that results in
1.0.22-0 being cached under %LOCALAPPDATA%\copilot\pkg\universal\)
- Launch Copilot CLI
- Issue any request that triggers normal operation
- Observe crash after a short period of use
Expected Behavior
Copilot CLI runs without crashing.
Actual Behavior
copilot.exe crashes with a Windows access violation. Multiple crash dumps were generated (15+, all on 2026-04-09 between 7:50 AM and 10:59 AM local time):
Exception code: 0xc0000005 (ACCESS_VIOLATION)
Faulting module: C:\Users\<user>\AppData\Local\copilot\pkg\universal\1.0.22-0\prebuilds\win32-x64\win_error_mode.node
Offset: 0x1be7
Runtime logs end abruptly mid-request with no graceful shutdown. As a secondary symptom, the terminal is left in mouse-reporting mode (ANSI cleanup is bypassed by the crash), requiring the terminal tab to be reopened.
Root Cause Analysis
The launcher in copilot.exe scans pkg\universal\*\app.js and always loads the highest semver version directory, regardless of which version WinGet installed or what COPILOT_AUTO_UPDATE is set to.
win_error_mode.node was first introduced in v1.0.21. The file in v1.0.22-0 has the same byte size as v1.0.21 (131,872 bytes) but a different SHA256 hash — indicating a different (broken) build was shipped.
win_error_mode.node presence and hashes
| Version |
win32-x64 present? |
SHA256 (x64) |
| 1.0.13-0 |
❌ No |
— |
| 1.0.13-1 |
❌ No |
— |
| 1.0.17 |
❌ No |
— |
| 1.0.18 |
❌ No |
— |
| 1.0.21 |
✅ Yes (131872 B) |
BFA2D4B9...20947DC9 ← stable |
| 1.0.22-0 |
✅ Yes (131872 B) |
32CF75A6...4D29C99E ← crashes |
Crashes began at 7:50 AM on 2026-04-09 — approximately 13 hours after v1.0.22-0 was downloaded at 7:09 PM on 2026-04-08.
Workaround
Replace the broken win_error_mode.node in 1.0.22-0 with the known-good version from 1.0.21:
# Backup the broken file
Copy-Item "$env:LOCALAPPDATA\copilot\pkg\universal\1.0.22-0\prebuilds\win32-x64\win_error_mode.node" `
"$env:LOCALAPPDATA\copilot\pkg\universal\1.0.22-0\prebuilds\win32-x64\win_error_mode.node.bak"
# Replace with the stable 1.0.21 build
Copy-Item "$env:LOCALAPPDATA\copilot\pkg\universal\1.0.21\prebuilds\win32-x64\win_error_mode.node" `
"$env:LOCALAPPDATA\copilot\pkg\universal\1.0.22-0\prebuilds\win32-x64\win_error_mode.node" -Force
This keeps v1.0.22-0's app.js (no feature regression) while using the stable native addon.
Alternatively, disable v1.0.22-0 entirely so the launcher falls back to v1.0.21:
Rename-Item "$env:LOCALAPPDATA\copilot\pkg\universal\1.0.22-0" "1.0.22-0.disabled"
Impact
- Copilot CLI is completely unusable on affected systems
COPILOT_AUTO_UPDATE=false (set at both User and Machine level in the registry) does not prevent the launcher from using the highest-version cached directory
- Downgrading via WinGet alone does not fix the issue for the same reason
Related
Affected version
No response
Steps to reproduce the behavior
No response
Expected behavior
No response
Additional context
No response
Describe the bug
Summary
copilot.execrashes with an access violation (0xc0000005) inside the native Windows addonwin_error_mode.nodeshipped with v1.0.22-0. The crash is reproducible and consistent. The same-size file from v1.0.21 is stable — v1.0.22-0 shipped a broken build of this native addon.Environment
Steps to Reproduce
1.0.22-0being cached under%LOCALAPPDATA%\copilot\pkg\universal\)Expected Behavior
Copilot CLI runs without crashing.
Actual Behavior
copilot.execrashes with a Windows access violation. Multiple crash dumps were generated (15+, all on 2026-04-09 between 7:50 AM and 10:59 AM local time):Runtime logs end abruptly mid-request with no graceful shutdown. As a secondary symptom, the terminal is left in mouse-reporting mode (ANSI cleanup is bypassed by the crash), requiring the terminal tab to be reopened.
Root Cause Analysis
The launcher in
copilot.exescanspkg\universal\*\app.jsand always loads the highest semver version directory, regardless of which version WinGet installed or whatCOPILOT_AUTO_UPDATEis set to.win_error_mode.nodewas first introduced in v1.0.21. The file in v1.0.22-0 has the same byte size as v1.0.21 (131,872 bytes) but a different SHA256 hash — indicating a different (broken) build was shipped.win_error_mode.nodepresence and hashesBFA2D4B9...20947DC9← stable32CF75A6...4D29C99E← crashesCrashes began at 7:50 AM on 2026-04-09 — approximately 13 hours after v1.0.22-0 was downloaded at 7:09 PM on 2026-04-08.
Workaround
Replace the broken
win_error_mode.nodein1.0.22-0with the known-good version from1.0.21:This keeps v1.0.22-0's
app.js(no feature regression) while using the stable native addon.Alternatively, disable v1.0.22-0 entirely so the launcher falls back to v1.0.21:
Impact
COPILOT_AUTO_UPDATE=false(set at both User and Machine level in the registry) does not prevent the launcher from using the highest-version cached directoryRelated
%LOCALAPPDATA%\CrashDumps\copilot.exe.*.dmpAffected version
No response
Steps to reproduce the behavior
No response
Expected behavior
No response
Additional context
No response