Windows Desktop: intermittent codex.exe 0xc0000409 crashes during work; Store update can also interrupt sessions

Summary

Codex Desktop on Windows intermittently exits during normal work. Windows Error Reporting records a native codex.exe application crash with 0xc0000409 (fast-fail / stack-buffer-overrun status). The same machine also experienced a separate Store-update lifecycle restart without a WER crash event. These should be treated as two distinct failure modes.

Environment

• Platform: Windows 11 x64, build 10.0.26100.8655
• Distribution: Microsoft Store package OpenAI.Codex
• Current package when reporting: 26.707.3563.0
• A newer Store package 26.707.3748.0 was detected/staged during the latest restart sequence
• Affected historical package versions with WER crashes: 26.616.6631.0, 26.616.10790.0, 26.616.4196.0, 26.623.4041.0, 26.707.3351.0

Failure mode A: native app crash while working

Windows Application Error event (latest captured example):

Time: 2026-07-09 17:16:18 local
Faulting application: codex.exe
Package version: OpenAI.Codex_26.707.3351.0
Faulting module: codex.exe
Exception code: 0xc0000409
Fault offset: 0x000000000cc24cf1
WER Report ID: ad0bf716-8e11-4889-8524-c21506528cd6

A Windows crash dump was generated. I can provide it privately if a maintainer requests it.

Immediately before that crash, the Codex desktop log contained repeated state/routing errors such as:

[electron-message-handler] Conversation state not found
[electron-message-handler] Received item started/completed for unknown conversation
[electron-sampler] Failed to collect child process snapshot

The sampler failure attempted to build an exceptionally large PowerShell process filter over a very large set of child PIDs. This is correlation, not a proven cause, but it occurs in the minute before the WER crash.

The crash pattern has persisted across several package updates, so it does not appear to be a one-off damaged package installation.

Failure mode B: Store update lifecycle unexpectedly interrupts the app

On 2026-07-09, a separate exit/restart occurred with no new Application Error and no new crash dump:

21:58 local  [windows-store-updater] Checking Windows Store for package updates
21:58 local  Windows Store found/staged OpenAI.Codex_26.707.3748.0
21:59 local  Windows-AppModel-Runtime destroyed the existing AppX container
22:03 local  Windows-AppModel-Runtime created a new Codex process/container

The Store telemetry included AllowForcedAppRestart: false, yet the active task was interrupted. The actually running package after the restart still reported 26.707.3563.0, suggesting the update was staged but not cleanly activated for the current user.

This update-lifecycle symptom appears related to #27146, but it was not a 0xc0000409 WER crash in this occurrence.

Expected behavior

• Normal work, including many active local processes/conversations, must not terminate the desktop app.
• Process sampling and conversation-state mismatches should fail gracefully rather than fast-failing the main process.
• Store update discovery/staging must not terminate an active Codex session unless the user explicitly accepts a restart; if restart is necessary, the app should clearly explain it and preserve/recover active task state.

Notes

• The system was stable at the crash time: no system reboot event and no memory exhaustion.
• Disk pressure was not present (approximately 102 GB free on the system drive; pagefile peak roughly 3.4 GB).
• This is not caused by a custom Git wrapper; the same wrapper only addresses visible terminal-window spawning and is separate from the codex.exe application crash.