Windows desktop: bundled codex.exe app-server repeatedly killed with 0xC000013A (STATUS_CONTROL_C_EXIT) mid-turn; app broadcasts fatal_error_broadcasted and restarts

Summary

On Windows, the Codex desktop app repeatedly loses its bundled codex.exe app-server: the backend process is killed with exit code 3221225786 (0xC000013A, STATUS_CONTROL_C_EXIT) in the middle of an active turn, the app logs [AppServerConnection] Codex CLI process exited classifiedAsExpected=false followed by fatal_error_broadcasted, shows the crash/restart experience, and spawns a new backend. This repeated several times within minutes during normal interactive use.

The exit code indicates the backend received a console control event (Ctrl-C / console close / taskkill without /F) rather than faulting on its own — i.e. something in the desktop app's process management appears to be killing its own app-server. Electron breadcrumbs show the main process spawning taskkill.exe (exit 128) and git.exe (exit 1) in a repeating ~20–30 s cleanup cycle around the deaths.

Environment

• Codex desktop (MSIX): OpenAI.Codex_26.727.6591.0_x64 — latest available at time of report
• App-managed CLI/backend: codex-cli 0.146.0-alpha.9.2; app release tag codex@26.727.51351
• Bundled Chromium: 150.0.7871.182
• Windows 11 Pro 10.0.26200

Timeline (2026-08-03, from ~/.codex/logs_2.sqlite logs table, local time)

Backend (app-server) process generations, each spawned by the desktop app:

| generation | first log | last log | how it ended |
|---|---|---|---|
| gen 1 | 17:37:27 | 17:39:20 | abrupt — last rows are routine account/read handling; no shutdown sequence |
| gen 2 | 17:39:28 | 17:41:07 | abrupt — died while actively streaming item/commandExecution/outputDelta events (1/s); killed at 17:41:09 with 0xC000013A |
| gen 3 | 17:41:13 | — | respawned by the app |

There is no shutdown logging, no Windows Error Reporting event, and the Crashpad database is empty for these deaths — consistent with external termination via console control rather than a native fault.

Sentry scope breadcrumbs (.../LocalCache/Roaming/Codex/web/Codex/sentry/scope_v3.json) around the gen-2 death:

17:40:26 warning child_process  Child process exited with code '128'  spawnfile=C:\WINDOWS\System32\taskkill.exe
17:40:27 warning child_process  Child process exited with code '1'    spawnfile=C:\Program Files\Git\cmd\git.exe
17:40:27 warning child_process  Child process exited with code '128'  spawnfile=C:\WINDOWS\System32\taskkill.exe
17:41:09 warning child_process  Child process exited with code '3221225786'  spawnfile=...\app\resources\codex.exe
17:41:09 error   console        [AppServerConnection] Codex CLI process exited classifiedAsExpected=false code=3221225786 connectionId=4 signal=null transport=stdio
17:41:09 error   console        [AppServerConnection] fatal_error_broadcasted errorMessage="  (code=3221225786, signal=null). ..."

The git.exe + taskkill.exe (exit 128 = no matching process) pair from the main process repeats at 17:46:58, 17:47:17, 17:47:46, 17:47:56.

Earlier the same morning the UI itself hung: Windows Event Log ID 1002 The program ChatGPT.exe version 150.0.7871.182 stopped interacting with Windows and was closed plus two MoAppHang WER events (17:01 UTC).

Troubleshooting already ruled out

• logs_2.sqlite had grown to 1.34 GB; rotated it (per #27741 / #29237). Backend deaths continued with a fresh <1 MB DB.
• config.toml fully validated against the config reference; an invalid approvals_reviewer value and a dangling plugin/marketplace reference were fixed. Deaths continued.
• A version-skewed npm CLI (0.145.0) sharing CODEX_HOME was updated to 0.146.0. Deaths continued.
• No crash/resume loop markers (no rollout found, overrides ignored) in the logs — this is the primary kill event, not the #16271 aftermath loop.
• The in-app Browser sidebar was in use during the session (browser-sidebar-page-states.json written ~17:45), so #32334 / #33762 may be related, but gen 2 died mid-commandExecution streaming, not obviously on a webview event.

Expected behavior

• The desktop app's cleanup/cancel path should never deliver a console control event (or taskkill) to its own app-server process.
• If the backend does die, the exit should be classified and recovered gracefully (resume the thread) instead of broadcasting a fatal error to the UI.

Related issues

#16271, #21761, #31353, #32334, #33762, #27741, #29237