[Windows Desktop 26.727.6591.0] app-server crashes under commit-memory exhaustion and does not auto-recover

What version of the Codex App are you using (From “About Codex” dialog)?

OpenAI.Codex 26.727.6591.0 (Microsoft Store / MSIX)

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64 (Windows 11, 16 GB RAM, Windows-native workspaces; not WSL)

What issue are you seeing?

The Windows desktop UI remains open after severe system commit-memory exhaustion, but the bundled codex.exe app-server process terminates. Sending any subsequent message displays:

Codex app-server process is not available

Only fully restarting the Codex/ChatGPT desktop app restores operation. The UI does not automatically restart or reconnect to the app-server after physical and virtual memory become available again.

Windows Event Viewer and Windows Error Reporting confirm actual native codex.exe crashes. On 2026-08-02, I observed at least eight separate app-server crashes. The recurring crash signature was:

Faulting application: codex.exe
App package version: 26.727.6591.0
Exception code: 0xc0000409
Fault offset: 0x000000000d71d4a1
Application timestamp: 0x6a6a8fcf
Faulting module timestamp: 0x6a6a8fcf
Fast-fail subcode reported by the Application Error event: 7

The packaged executable path is:

%ProgramFiles%\WindowsApps\OpenAI.Codex_26.727.6591.0_x64__2p2nqsd0c76g0\app\resources\codex.exe

What steps can reproduce the bug?

The direct trigger is now confirmed to be a runaway Node.js development process exhausting Windows commit memory. The Node process was associated with a local frontend development workflow, not with the bundled Codex app-server itself.

1. Launch Codex Desktop on Windows and use project conversations normally.
2. Run a local Node.js development task that leaks or reserves approximately 40-50 GB of virtual/commit memory.
3. Windows reports virtual-memory exhaustion (System event 2004).
4. Within several seconds, the bundled codex.exe app-server terminates with 0xc0000409.
5. End the runaway Node process so memory returns to normal.
6. The Codex UI remains open, but sending any message reports Codex app-server process is not available.
7. A full desktop-app restart is required to recover.

Observed correlations from Windows events:

18:49:42  node.exe 42.45 GB -> codex.exe crash at 18:49:45
19:15:53  node.exe 42.86 GB -> codex.exe crash at 19:16:04
19:31:17  node.exe 40.75 GB -> codex.exe crash at 19:31:23
19:36:18  node.exe 47.17 GB -> codex.exe crash at 19:36:23
19:57:37  node.exe 47.38 GB -> codex.exe crash at 19:57:43

Later resource-exhaustion events captured separate runaway Node processes at approximately 50.1-50.7 GB, reinforcing the trigger diagnosis.

During the 22:52-22:54 exhaustion episode, unrelated desktop processes also failed to start. For example, wetype_renderer.exe displayed Windows application error 0xc000012d (STATUS_COMMITMENT_LIMIT). At that point all active Codex conversations stopped making progress and the desktop app had to be restarted manually. This confirms that the initial trigger was system-wide commit exhaustion, not a network failure or a single damaged Codex conversation.

After the Node process exits, the machine recovers to approximately 8.7 GB free physical RAM and 18.6 GB free virtual memory, but the existing Codex UI still cannot recover its app-server connection.

What is the expected behavior?

Ideally the app-server should degrade or exit cleanly under extreme system memory pressure. More importantly, once resources recover, the desktop app should automatically restart the app-server and reconnect existing conversations instead of leaving a permanently unusable UI that requires a complete application restart.

Additional information

The latest archived WER report confirms:

AppName=codex.exe
ReportIdentifier=eec2c1cb-417e-4839-af2c-2bfa06c10427
IntegratorReportIdentifier=b718cc03-56b1-4242-b28d-00807f2636a4
Sig[7].Value=000000000d71d4a1

At one crash time, codex-code-mode-host.exe also terminated with 0xc0000409. The original Node memory leak is an application-project issue, but the Codex-specific issue reported here is that the desktop UI survives while its app-server dies and is never automatically restored after memory pressure has cleared.

I can provide additional sanitized WER fields or a crash dump if maintainers specify the preferred collection procedure.