Repository navigation
Windows desktop: bundled codex.exe app-server repeatedly killed with 0xC000013A (STATUS_CONTROL_C_EXIT) mid-turn; app broadcasts fatal_error_broadcasted and restarts #36778
Description
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 tagcodex@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.sqlitehad 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.tomlfully validated against the config reference; an invalidapprovals_reviewervalue and a dangling plugin/marketplace reference were fixed. Deaths continued.- A version-skewed npm CLI (0.145.0) sharing
CODEX_HOMEwas 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.jsonwritten ~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-commandExecutionstreaming, 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.
Activity
github-actions commentedon Aug 3, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
Mitsukiyukiii commentedon Aug 3, 2026
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.
truemanandy168-cmyk commentedon Aug 21, 2026
Independent reproduction on a newer Windows Desktop build, with a deterministic trigger and a verified local mitigation.
Environment
26.818.3698.00.149.0-alpha.4codex.exeapp-server exited and was respawned.Observed behavior
On 2026-08-21 the app-server exited repeatedly with:
At least 12 matching exits were recorded during one workday. There were no corresponding Windows Error Reporting, Defender, or resource-exhaustion events.
The latest affected generation started at 17:34:40 local time and exited at 17:36:47. The surfaced “Most recent error” was:
The desktop then spawned another app-server generation.
Deterministic local trigger
A Python test launched from a Codex tool call used this POSIX liveness idiom:
On Windows this can route through
GenerateConsoleCtrlEvent/CTRL_C_EVENT. In the Desktop Code Mode console domain it can terminate both the tool process and the shared app-server, yielding exactly0xC000013A. This matches the corrected reproduction already documented in #32653.The first kill also left an unmatched custom tool call. Resuming the affected task then hit the “Custom tool call output is missing” path, creating a secondary restart loop.
Verified mitigation
The Windows liveness probe was replaced with a non-signaling Win32 query:
OpenProcess(PROCESS_QUERY_LIMITED_INFORMATION)GetExitCodeProcessSTILL_ACTIVECloseHandleThe same complete local self-test then finished successfully:
No app-server restart occurred during the corrected run.
Additional Desktop override evidence
Adding this to
config.toml:correctly disables the feature in a standalone CLI query, but Desktop re-enables it after startup. Desktop logs show:
and app-server turn diagnostics still contain
UnifiedExec.Requested fixes
CTRL_C_EVENTto kill the shared app-server.unified_exec = falsesafety override in Desktop, or provide a supported Windows fallback switch.This comment omits account details, local paths, prompts, auth data, and call IDs.
Imagineer99 commentedon Aug 30, 2026
I’m seeing the same Windows Codex Desktop failure when enabling a local stdio MCP server.
The MCP server authenticates and initializes successfully, but Codex then repeatedly restarts its backend with exit code 3221225786 (0xC000013A), classifiedAsExpected=false, followed by fatal_error_broadcasted.
Disabling that MCP server and relaunching Codex stops the restarts. Re-enabling it reproduces the problem.