Repository navigation
Windows Codex Desktop 26.930.21537: recurring backend crash (0xc0000409) leaves app-server unavailable and active chats stalled #50324
Description
What version of the Codex App are you using (From “About Codex” dialog)?
The app's built-in update checker reports version 26.930.21537, build 12776, release channel prod, and status up_to_date.
Running the faulting backend executable with --version returns codex-cli 0.159.0-alpha.12.1.
What subscription do you have?
Not supplied in this report.
What platform is your computer?
Windows 10 Pro, x64, version 10.0.19045; approximately 32 GB RAM.
What issue are you seeing?
Since updating Codex Desktop, it repeatedly stops working after running for a while. The desktop window remains open, but:
- Submitting a message displays “Codex app-server process is not available.”
- New conversations cannot be started.
- Model/mode controls become unusable; I have also seen a provider-not-found message, although I do not have its exact text.
- Other active conversations appear to stop making progress.
- Restarting the app temporarily restores access, but the failure recurs.
Windows Application Error events confirm repeated crashes of the backend codex.exe. Three earlier crashes and the latest recurrence have the same exception code and fault offset.
What steps can reproduce the bug?
There is no deterministic minimal reproducer yet. The observed sequence is:
- Start Codex Desktop and continue normal coding work with several conversations active.
- Let the sessions run for a while.
- A backend crash occurs.
- Try submitting a message, starting a new conversation, or using the model/mode controls.
- The app reports that the app-server process is unavailable, and other active sessions appear stalled.
- Restart the app; it works temporarily, then the problem recurs.
In the latest observed run, the backend started at approximately 21:48 and crashed at 22:25 on October 2, 2026 (UTC+08:00).
What is the expected behavior?
Codex should remain usable during ordinary work. If the backend terminates, the desktop app should show a clear backend-crash error, recover the connection where possible, and clearly mark interrupted tasks and uncertain tool execution states. The UI should not leave conversations apparently running while new messages and controls are unusable.
Additional information
Sanitized crash evidence
All times below are October 2, 2026, UTC+08:00:
| Time | Faulting application | Exception code | Fault offset |
|---|---|---|---|
| 19:59:49 | codex.exe | c0000409 | 000000000e2f9321 |
| 20:56:27 | codex-code-mode-host.exe | c0000409 | 0000000000c605b1 |
| 21:06:13 | codex.exe | c0000409 | 000000000e2f9321 |
| 21:42:40 | codex.exe | c0000409 | 000000000e2f9321 |
| 22:25:18 | codex.exe | c0000409 | 000000000e2f9321 |
Latest Windows Error Reporting record:
Event type: BEX64
Faulting application and module: codex.exe
Application/module version: 0.0.0.0
Application/module timestamp: 6abeb15a
Exception code: c0000409
Exception data: 0000000000000007
Fault offset: 000000000e2f9321
WER report ID: 597a9830-0ce5-41bc-ac08-5c49c7d5f401
Sanitized executable path:
%LOCALAPPDATA%\OpenAI\Codex\bin\be3fd7e5c1969ff6\codex.exe
Desktop logs immediately after the latest crash include:
2026-10-02T14:25:30.516Z
method=thread/queue/list
error={"code":-32000,"message":"Codex app-server process is not available"}
2026-10-02T14:25:30.700Z
method=thread/list
error={"code":-32000,"message":"Codex app-server process is not available"}
Memory pressure and limitations
Windows did report virtual-memory exhaustion at 21:32, 21:38, and 21:41, before the 21:42 crash. At that time the pagefile was fixed at 1 GB. By the later diagnostic check, the C: pagefile was configured with initial/maximum values of 0/0 (system managed for that drive), and its allocated size had grown to approximately 4.9 GB. The 22:25 crash still occurred with the same fingerprint, and no newer Event ID 2004 resource-exhaustion warning was found. The machine had not yet rebooted after the pagefile change.
These observations do not prove or rule out an allocation failure or memory leak. Post-restart free-memory measurements are not crash-time telemetry. The exception code alone does not identify the root cause.
Configuration context
The default provider setting was openai when inspected. A legacy custom gateway provider definition and a custom model catalog are also present in the configuration; a clean default-configuration reproduction has not yet been performed. No credentials or gateway endpoint are included here.
Local WER records and redacted event/log extracts have been preserved. No usable crash dump or symbolized stack trace was available during this investigation. The logs also contain missing custom-tool-output errors in some conversations, but their relationship to the native crash is unknown.
Related reports reviewed: #31989, #38203, and #46201. They describe similar Windows crash or interrupted-task symptoms, but I cannot establish that they have the same cause as this build's recurring backend crash.
Activity
github-actions commentedon Oct 2, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
xiru0834-eng commentedon Oct 19, 2026
October 19 follow-up: native allocation-failure evidence on Desktop 26.1013.40934
Windows x64; Desktop 26.1013.40934, build 20770, production updater reports
up_to_date; bundled backend codex-cli 0.163.0-alpha.10.2. This adds evidence from the current environment; the earlier report's custom-provider context is not being asserted as a cause.Seven
codex.exeApplication Error events were found over seven days. The latest four occurred at 2026-10-18 02:10:27Z, 09:06:40Z, 15:21:29Z, and 2026-10-19 02:06:26Z, with exception0xc0000409, fault RVA0x0ef065c1, and fast-fail parameter 7. Exception code alone should not be interpreted as proof of stack-buffer corruption.Three existing minidumps were analyzed locally. Offline PE unwind metadata yielded 29 application frames for each of the first two dumps, with all 28 return addresses checked against call-instruction ends; the third yielded 23 frames with all 22 checked. No private PDBs were available, so this is not a private-symbol stack trace.
The first two dumps have the same allocation-failure path. Disassembly and exact-build source correspondence indicate JSON escaping/serialization of memory-stage evidence, raw-vector growth, and a failed allocation of 689,603,584 bytes (alignment 1). Process private commit in those dump streams was approximately 16.27 and 16.38 GiB respectively.
A long-running local rollout is 14,475,065,854 bytes (~13.48 GiB), 456,765 complete JSONL records, largest record ~13.15 MiB (counted by bounded streaming, not loading the whole file). The memory-stage job for that history started approximately 55 seconds before the second of those crashes and remained unfinished in the inspected job state.
The exact public source corresponding to this backend tag is commit
4ebc485ca321243727539187169425fcf972f2c4. Its phase-1 path callsRolloutRecorder::load_rollout_items, retains the whole history, then filters/clones and serializes evidence before prompt truncation. This supports excessive whole-history memory processing as a cause for those two matching dumps, rather than establishing the cause of every crash.PR #53940 replaces this path with bounded recent-evidence reads (8 MiB evidence budget, 1 MiB per record). Please confirm delivery of that fix in the supported Windows Desktop backend. The installed build's corresponding source still uses the older path despite the updater reporting current.
The third dump differs: process private commit ~1.05 GiB, failed allocation ~1 MiB, and a different code-mode host protocol business stack. Do not assume all seven events share the memory-stage trigger. Dump collection can lag the exception and resources may already have been released; system-memory snapshots do not prove or rule out global exhaustion.
A narrow mitigation used the backend's official
thread/memoryMode/setAPI to disable memory extraction only for the oversized history, with database readback verification. The conversation and existing history were retained; this is not proof of cancelling any already-running task or repairing the installed backend.Separately, message-sending stalls recurred with attachment-metadata request-queue saturation and no new native crash; those new queue findings are tracked in #48917. Please keep backend allocation failures and client queue saturation as distinct investigations, and validate recovery/error presentation when the backend exits.
No raw dump, log, transcript, history file, conversation ID, personal path or credential is uploaded. The report contains only sanitized measurements and public-source references. Prepared with Codex assistance at the user's explicit request.