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

[Mitsukiyukiii]

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 Desktop launch can fail when logs_2.sqlite grows large: app-server SQLite pool times out during startup #27741 / Bug: CLI crashes with SIGTRAP (trace trap) when logs_2.sqlite exceeds ~200MB #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 Any Single Engine Crash Leaves Orphaned Threads That Cause a Persistent Crash/Resume Loop #16271 aftermath loop.
• The in-app Browser sidebar was in use during the session (browser-sidebar-page-states.json written ~17:45), so Codex Desktop crashes after in-app Browser sidebar webview creation on Windows #32334 / Windows Codex Desktop silently exits after in-app Browser WebView navigation; disabled Browser plugin is re-enabled on restart #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

[github-actions]

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

• [Windows][26.721.4979.0] app-server disconnect/recovery causes full desktop app termination under concurrent tasks #35782

Powered by Codex Action

[Mitsukiyukiii]

Reviewed #35782 for the duplicate flag - not a duplicate, though likely a sibling in the same app-server lifecycle area. #35782 reports the app-server disconnecting under concurrent load (EPIPE, IAB window-lifecycle errors) followed by termination of the entire desktop window after a recovery attempt, with no exit code identified. This issue documents a different mechanism: the bundled app-server being killed with 0xC000013A (STATUS_CONTROL_C_EXIT) mid-turn - implicating the desktop app's own cleanup/taskkill cycle - while the app itself survives and respawns the backend, broadcasting fatal_error_broadcasted each time. Keeping this open so the exit-code evidence stays actionable; happy to consolidate if maintainers determine a shared root cause.