›_ Codex Issues
Codex Issues / #31989

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

Open 💬 5 comments Opened Jul 10, 2026 by rwang23
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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.

View original on GitHub ↗

5 Comments

github-actions[bot] contributor · 1 month ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #31353
  • #31583

Powered by Codex Action

dingjianhui123-create · 1 month ago

I can reproduce the same exact Windows Desktop crash on the actually running Store package OpenAI.Codex 26.707.3748.0 (bundled app-server 0.144.0-alpha.4) and have additional dump evidence.

The fatal signature reproduced twice today:

  • exception: 0xC0000409
  • fast-fail: FAST_FAIL_FATAL_APP_EXIT
  • fault offset: codex+0xcc24cf1
  • bucket: FAIL_FAST_FATAL_APP_EXIT_c0000409_codex.exe!Unknown
  • failure hash: {de980cc6-e79f-2a5a-de3a-58ef8955356d}
  • commit peak: 689 MB
  • process uptimes: 29 seconds and 34 seconds
  • last active/incomplete request in both incidents: plugin/list

The first incident logged this exact error:

Codex CLI process exited classifiedAsExpected=false code=3221226505
Most recent error: memory allocation of 399431958765 bytes failed

That is a bogus ~372 GiB request, not physical-memory exhaustion. The second occurrence generated a new dump with the same offset, bucket, failure hash, and 689 MB commit peak.

A separate crash in the same build was detected in RtlFreeHeap:

  • FAST_FAIL_UNEXPECTED_HEAP_EXCEPTION / 0xC0000409
  • bucket: FAIL_FAST_UNEXPECTED_HEAP_EXCEPTION_c0000409_codex.exe!Unknown
  • commit peak: 737 MB
  • process uptime: 12 seconds

Immediately before the fatal allocation occurrences, structured logs were concentrated in plugin/list, app/list, plugin manifest/marketplace, and App/resource initialization. The latest fatal process wrote 1,002 structured-log rows in 23 seconds, with plugin/list still active at the end. The unexpected-heap process was in thread/resume, MCP/Apps initialization, paginated codex_apps resources, and connection recovery.

I also observed multiple silent Desktop/AppX container exits without WER or Crashpad dumps. This confirms that the native crash persists in package 26.707.3748.0 and is not only an update-staging interruption.

Dump SHA-256 values:

  • fatal allocation #1: 1DD24515A7A672DD7BA0B9F7B8860CF497E69AB99666EA163607FE15A4A01687
  • unexpected heap exception: 911776C4DB298F480432E287E0199F2956663A08C0D852F5E43CCA23876A022A
  • exact fatal recurrence: FED0741F40200A6D85076D1695B5609CC2E245F9ADA57A570D000CD62E1DFAC4

Raw dumps are not attached publicly because they may contain process memory, task text, and local paths. I can provide them through a secure OpenAI support channel if requested.

I initially filed #32361 with the full timeline before the duplicate bot surfaced this issue. I am consolidating the evidence here and will close #32361 as a duplicate.

CainDez · 1 month ago

Reproduced again on the newer Windows Store build, with a deterministic startup loop and an effective version-isolation workaround.

New affected environment

  • Windows 11 x64 build 26100.8875
  • Store package: OpenAI.Codex 26.721.4979.0
  • Desktop/Chromium version: 150.0.7871.128
  • Bundled app-server: codex-cli 0.146.0-alpha.3.1
  • Bundled app-server command:

``text
codex.exe -c features.code_mode_host=true app-server --analytics-default-enabled
``

Failure signature

During one incident window I captured more than 95 app-server crashes. All inspected Application Error events had the same signature:

Faulting application: codex.exe
Faulting module: ntdll.dll 10.0.26100.8875
Exception: 0xC0000409
Fault offset: ntdll+0x13a375
Exit code: 3221226505

dumpchk reports fast-fail subcode 0x23:

FAST_FAIL_UNEXPECTED_HEAP_EXCEPTION

Two independently captured dumps have the same stack shape on a Tokio worker thread:

RtlFreeHeap
codex+0xd85cbd
codex+0x182352a
codex+0x2a63a91
...

The app-server usually completes the initialize handshake successfully, remains alive for roughly 1.8–3 seconds, then exits. Desktop restarts it every few seconds and eventually shows “ChatGPT stopped unexpectedly / Codex app-server is not available.”

Isolation results

The following did not stop the crash:

  1. Validating config.toml with an independent TOML parser.
  2. Replacing the entire user config with an otherwise empty config.toml.
  3. Setting both plugins=false and plugin_hooks=false.
  4. Removing a separately corrupted process-notification cache.
  5. Relaunching the Store package after confirming AppX package status is Ok.

The plugin-manifest, remote-control, and config warnings shown as the “most recent error” varied between crashes, and many crashes had no stderr reason at all. The native exception and dump stack remained identical, so those warnings appear to be incidental last-log messages rather than the heap-corruption cause.

Working mitigation / version bisect

The packaged binary and a cached copy have the same SHA-256 and both report 0.146.0-alpha.3.1.

I then set the supported desktop override:

CODEX_CLI_PATH=<global npm Codex 0.145.0 codex.exe>

After fully restarting Desktop:

  • Desktop launched normally.
  • Its app-server command used codex-cli 0.145.0.
  • Exactly one app-server remained running.
  • No new 0xC0000409 event occurred during two launch/observation cycles.
  • A second launch through the normal Start-menu/AppX activation path also remained stable.

The Microsoft Store reported no newer package than 26.721.4979.0 at the time of testing.

This strongly narrows the regression to the bundled 0.146.0-alpha.3.1 app-server (or a Desktop path specific to that protocol/version), rather than the user's TOML configuration or plugin catalog. Comparing heap ownership/cancellation changes between 0.145.0 and 0.146.0-alpha.3.1 may be useful.

Raw dumps are not attached publicly because they may contain process memory, local paths, and task data. I can provide them through a secure OpenAI support channel if requested.

yotch0928-collab · 26 days ago

Adding a new datapoint: this Windows native-crash regression appears to persist in the current Microsoft Store package.

Versions

  • Microsoft Store package: OpenAI.Codex 26.727.6591.0
  • Bundled app-server version observed in runtime headers: 0.146.0-alpha.9.2
  • Desktop client version observed in runtime headers: 26.727.51351
  • Native Windows agent, not WSL
  • Windows x64

Crash signature

Two consecutive crashes occurred on 2026-08-02:

  • 08:43:07 JST
  • 08:44:25 JST

Both had:

  • Faulting application: codex.exe
  • Faulting module: codex.exe
  • Exception code: 0xc0000409
  • Fault offset: 0x000000000d71d4a1
  • Fast-fail parameter: 7

WER report IDs:

  • 1ab42985-59c2-452e-a25f-3ba0f62317df
  • f96a9a6c-31c0-4e99-8641-c629996ea214

Windows generated two crash dumps:

  • Size: 5,447,784 bytes

SHA-256: 4F2CEBAC469404E3F84E405A5929BBEE792D45DEF3D26CDF9271B24CE4F74C4D

  • Size: 3,844,675 bytes

SHA-256: 52901694F85F9C89931DA9E0ACF124DB80C77263654D5B086BF01E22A5BB5A3C

I can provide the dumps through a secure/private upload channel, but have not attached them publicly because they may contain process memory.

What was happening at the time

At the first crash, four local tasks had in-flight custom exec tool calls:

  • one documentation/dependency lookup
  • two polls of already-running commands
  • one read-only shell inspection

Two task working directories were Git repositories and two were not, so Git repository detection does not appear to be the sole trigger.

After the process crash, each of those four task session logs contained exactly one custom_tool_call without the corresponding custom_tool_call_output. Retrying the affected tasks then produced:

Custom tool call output is missing

The second native crash occurred during the resulting recovery/retry activity.

This gives a direct observable sequence:

in-flight tool calls → codex.exe native crash → missing tool outputs → task recovery failure

This may overlap with the tool-call regression reported in #34907.

Resource and integrity checks

The machine was not under obvious resource pressure at the incident:

  • approximately 13.84 GB physical RAM
  • approximately 5 GB available RAM
  • approximately 138 GB free on the system drive

One affected task had approximately 68,399 context tokens, well below the observed auto-compaction and full-context limits, so context exhaustion does not appear to explain this incident.

The local logs_2.sqlite file had grown to approximately 1.33 GB. SQLite integrity checks passed, and roughly 90% of its pages were on the freelist. An online incremental vacuum reduced it to approximately 134.8 MB without deleting log rows. This may have amplified I/O or runtime pressure, but it is not proven to be the root cause.

Recovery performed

I backed up the affected session files and inserted explicit interrupted-result records for only the four orphaned tool calls. No successful result was inferred or fabricated.

After repair:

  • all four sessions were valid JSONL
  • every custom tool call had exactly one corresponding output
  • SQLite quick_check returned ok
  • no additional native crash was observed during the subsequent observation window

The local sessions are usable again, but the underlying bundled Windows runtime issue remains.

Could you confirm whether this belongs to the same bundled 0.146.x app-server/native crash regression already tracked here, and provide a secure channel for uploading the two crash dumps if needed?

JacobShen · 2 days ago

Adding a new datapoint: this Windows native-crash issue remains reproducible on newer Codex Desktop builds.

Environment:

  • Windows 11 Pro x64, build 26200
  • Microsoft Store package: OpenAI.Codex 26.818.8289.0
  • Bundled app-server: 0.149.0-alpha.4.3

Observed:

  • codex.exe exits with 3221226505 / 0xC0000409, fast-fail parameter 7.
  • Fault offset on 26.818.8289.0: 0x000000000ced0251.
  • Desktop logged:

memory allocation of 2923760 bytes failed

  • Windows Resource-Exhaustion-Detector events identified codex.exe as the leading virtual-memory consumer, reporting approximately 102–119 billion bytes before failure.
  • The crash reproduced 5 times on 26.818.8289.0 and 12 times on 26.818.5229.0 during Aug 24–25.
  • After Desktop automatically restarts the app-server, codex.exe private memory returns to approximately 190 MB.
  • WER signature:
  • Event: MoBEX
  • P9: c0000409
  • P10: 7
  • Bucket: 8954ab4b8d7c0e05d29a4db34a43e41f
  • Latest dump size: 3,451,019 bytes
  • Dump SHA-256:

C120A36B6307D0700667A986080A8DBA8FAF620D6713A4E31487728384DD34A4

This appears to be the same Windows app-server native-crash family, now reproducing on app-server 0.149.0-alpha.4.3.

Raw dumps and full logs are preserved locally but are not attached publicly because they may contain task content, local paths, and process memory. I can provide sanitized excerpts or upload them through a private support channel if maintainers specify one.