launch_engine ACCESS_VIOLATION (0xC0000005) on Windows after auto-update replaces binary

[yoziv]

Describe the bug

After copilot.exe is auto-updated (WinGet package replaced in-place), the next launch immediately crashes with exit code -1073741819 (0xC0000005 — ACCESS_VIOLATION) at the launch_engine step. No session starts — the crash happens before any interaction.

A retry shortly after succeeds with the same binary, suggesting a race condition between the auto-updater replacing the binary and the launch attempt.

Affected version

GitHub Copilot CLI 1.0.26-0

Environment

• OS: Windows 11 Insider (10.0.26200), x64
• Install method: WinGet (GitHub.Copilot_Microsoft.Winget.Source)
• Terminal: Windows Terminal
• Copilot plan: Enterprise

Evidence of auto-update as trigger

copilot.exe      — 2026-04-14 13:52:23 (SHA256: 73A491F4C31AEF24F7E2DA68D9227A93B201C3B1167BE42810B37803FEE9717D)  <- new
copilot.exe.old  — 2026-04-12 12:11:50 (SHA256: 10A6B746EE7A1A216084F10AE316BCE2057BE4474B95FF133BDF2DA3C9391B30)  <- previous

The crash occurred at 15:08 (local), ~75 minutes after the binary was replaced. The .old backup confirms the auto-updater ran. A retry at ~15:19 succeeded with the identical new binary.

Crash output

🤖 Agency 2026.4.11.1
📦 Resolving Copilot CLI...
🧠 Copilot CLI at ...\GitHub.Copilot_Microsoft.Winget.Source_8wekyb3d8bbwe\copilot.exe
✅ Copilot CLI resolved (in 143 ms)
🔌 Loaded 9 MCP server(s) from ~/.copilot/mcp-config.json
Error: Agent execution failed: launch_engine - copilot.exe exited with non-zero status (exit code: -1073741819)

Hypothesis

The auto-updater writes copilot.exe while the old file may still be locked (Windows Defender scan, file system cache, or another copilot process). The replacement completes (the file exists and --version works), but the binary may be in an inconsistent state for engine launch until the OS fully releases handles/caches. This creates a transient window where launching immediately after update fails with ACCESS_VIOLATION.

What I've ruled out

• Binary corruption: copilot.exe --version returns 1.0.26-0 successfully — the binary itself is valid
• pkg cache: No ~/.copilot/pkg/universal/ directory exists (clean state)
• PATH issues: Single PATH entry pointing to correct binary
• session-store.db: 7.1 MB, not corrupt (valid SQLite header)
• Persistent crash: Retry with identical binary succeeds — crash is transient

Expected behavior

1. The auto-updater should ensure atomic binary replacement (write to temp -> rename, not in-place overwrite)
2. If launch fails immediately after update, the CLI should detect this and suggest retrying or rolling back to .old
3. Ideally: a short validation check after update before handing off to the new binary

Related

• Intermittent ACCESS_VIOLATION (0xC0000005) crash on Windows during AI model requests #2387 — Intermittent ACCESS_VIOLATION during mid-session (same exit code, different trigger — possibly same underlying native crash, different entry point)