Windows: app-server killed with STATUS_CONTROL_C_EXIT (0xC000013A) mid command execution; regressed in 26.818.5229 after being fixed post-26.810

Open 💬 8 comments Opened Aug 23, 2026 by baibaibai19910706

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

On Windows 10 (19045), the desktop app-server engine is repeatedly terminated with exit code 3221225786 (0xC000013A, STATUS_CONTROL_C_EXIT) a few minutes into any agent turn that executes local shell commands. Chat-only / idle sessions never die. The desktop shell shows "ChatGPT stopped unexpectedly" and restarts the engine; resuming threads with pending command turns re-triggers the kill, producing a crash/restart loop that makes the app unusable for local agent work.

The bug has now regressed twice across auto-updates — version bisection below, from one machine observed continuously over ten days.

Version timeline

All kill events from shell logs (%LOCALAPPDATA%\Codex\Logs\..., line Codex CLI process exited classifiedAsExpected=false code=3221225786):

| Store build | Dates observed | Behavior |
|---|---|---|
| 26.803.x | through Aug 13 | stable |
| 26.810.4967 / .41047 / .52044 | Aug 14–16 | 24 engine kills across two active days; death within 2–5 min whenever commands ran |
| builds current Aug 17–22 | Aug 17–22 | zero kills in six days; on Aug 23 daytime a single engine instance ran 15 h continuously with command activity |
| 26.818.5229 (auto-updated Aug 23 ≈12:20 UTC) | Aug 23 evening | first kill within 8 minutes of the update landing; identical signature |

Signature

Exit code always 3221225786, signal=null, classifiedAsExpected=false.
In the engine's internal log DB (logs_2.sqlite), the final rows before every death are item/commandExecution/outputDelta TRACE events — the engine dies mid command-output streaming. No ERROR or panic is logged; the process ends abruptly.
No WER report and no Application Event Log entry — consistent with a console control event (CTRL_C / CTRL_CLOSE delivered to the engine's console process group), not an access violation.
Correlation holds across every observed session: windows containing commandExecution events die within minutes (e.g. a 1205-row session with 221 commandExecution events died at 3 min 48 s); windows with zero commandExecution never die (e.g. an 817-row, 10-minute active session — zero deaths).

Ruled out locally (each isolated and tested; the kill persisted)

config.toml rebuilt to near-stock (and temporarily read-only-locked so the app could not rewrite it)
logs_2.sqlite reset (was 763 MB; reproduced with a fresh small DB)
state / queue / memories DBs: pragma integrity_check ok, all sqlx migrations ok
oversized thread rollouts (48–51 MB JSONL) quarantined
notify hook target (codex-computer-use.exe) disabled — tested on both cua_node runtime generations
all custom MCP servers disabled
bundled runtime PowerShell (~/.cache/codex-runtimes/codex-primary-runtime/dependencies/native/powershell) replaced with MSI PowerShell 7.6.4
Microsoft Store pwsh execution-alias bypassed by installing MSI PowerShell 7 onto PATH
Windows elevated sandbox disabled ([windows] sandbox = "elevated" removed; verified zero sandbox-runner activity during a subsequent kill)
full app reinstall (same version), OS reboot; 64 GB RAM with 40+ GB free; no third-party EDR
VS Code extension and desktop confirmed at matching versions during tests

Workaround

Pinning the VS Code extension at 26.803.41515 restores a working command-execution path; the desktop app is stable as long as no local commands run.

Environment

Windows 10 Pro 10.0.19045 x64
Store package OpenAI.Codex, currently 26.818.5229.0
PowerShell 7.6.4 (MSI) and Windows PowerShell 5.1 both present

Possibly related (same exit code / restart loops): #16271, #21761, #33136.

Happy to provide shell-log or engine-log extracts for any of the kill events above.

View original on GitHub ↗

8 Comments

github-actions[bot] contributor · 4 days ago

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

#39964

Powered by Codex Action

hauomu · 4 days ago

Independent reproduction here on a second Windows machine, with the same .5229 signature.

Environment

Store package: OpenAI.Codex 26.818.5229.0
Windows: Microsoft Windows NT 10.0.26200.0 (x64)
CPU: Intel Core i5-13600KF
RAM: 32 GB
Bundled Codex PowerShell: 7.6.4, tested healthy (PWSH_OK, exit code 0)

Reproduction / frequency

The desktop app showed “ChatGPT stopped unexpectedly” roughly 5 times in ~10 minutes during active Codex use.

The Sentry breadcrumbs capture the same failure repeatedly:

Child process exited with code '3221225786'
[AppServerConnection] Codex CLI process exited classifiedAsExpected=false code=3221225786 connectionId=5 signal=null transport=stdio

followed by another occurrence on the restarted app-server:

[AppServerConnection] Codex CLI process exited classifiedAsExpected=false code=3221225786 connectionId=6 signal=null transport=stdio

So this is again 3221225786 == 0xC000013A / STATUS_CONTROL_C_EXIT, with signal=null and classifiedAsExpected=false.

As in the original report, I found no corresponding Windows Application Event Log crash and no Windows Error Reporting event for Codex/ChatGPT during the failures.

Additional observation: thread-store projection error immediately before the deaths

In my logs, the most recent internal Codex warning immediately before multiple app-server exits is consistently:

failed to project durable rollout for 01a02b6a-3474-7343-9f46-4ffff6f54790:
thread-store internal error: thread history projection for 01a02b6a-3474-7343-9f46-4ffff6f54790 expected ordinal 5001, got 5000

I don't know whether this projection error is causal or merely the last warning emitted before the separate STATUS_CONTROL_C_EXIT termination, but it repeats across app-server restarts and may be useful for correlation. I have not deleted/reset the affected thread so the state can be preserved for further diagnosis.

One other oddity: the installed/running package and codex.exe path are definitely .5229, while some retained Sentry event metadata still identifies the frontend release as codex@26.818.41509. That may simply be stale persisted Sentry state after the update.

This therefore appears to reproduce #40231 on a substantially different Windows build as well, rather than being specific to 19045 or the original machine.

hauomu · 4 days ago

Follow-up from the independent Windows reproduction I added earlier: I tried the Microsoft Store ChatGPT (Beta) channel as a workaround for the Stable 26.818.5229.0 0xC000013A / STATUS_CONTROL_C_EXIT regression.

Unfortunately, the Beta channel is also unusable on the same machine.

Stable vs Beta result

Stable: OpenAI.Codex 26.818.5229.0
  -> repeated app-server exits with 3221225786 / 0xC000013A
  -> desktop crash screen / unusable for command-heavy work

Beta: OpenAI.CodexBeta 26.727.4816.0
  -> blocked at “Finish Windows setup”
  -> setup retry reports “Windows setup didn't finish”
  -> launching Beta itself elevated does not help
  -> “Continue with limited access” also refuses to enter the app

For the Beta failure, UAC itself is healthy, both AppX packages report Status: Ok, the signed codex-windows-sandbox-setup.exe exists and validates as OpenAI-signed, and the Beta codex.exe app-server starts.

After repeated Beta setup attempts, however, there is still no setup_marker.json, no deny_read_acl_state.json, no setup_error.json, and no CodexSandbox* local users. The newest existing sandbox log was not updated during the retries, suggesting the Beta onboarding flow is failing before helper invocation rather than inside ACL/WFP/DPAPI setup.

I opened a separate report for that Beta regression: #40346.

The practical impact is that both current Windows desktop channels are blocked on this machine: Stable by this .5229 app-server termination regression, and Beta by a separate onboarding/setup regression. That leaves CLI as the only viable Codex path for getting work done.

BWdhZ · 4 days ago

Additional Windows reproduction/evidence from Codex Desktop 26.818.8289.0 (the same behavior was also observed before the update on 26.818.3698.0).

The Electron shell itself did not produce an AppCrash or dump. The bundled codex.exe app-server repeatedly exited and was restarted. Relevant sanitized desktop-log sequence:

Custom tool call output is missing for call id: <redacted>
Codex CLI process exited classifiedAsExpected=false code=3221225786

3221225786 == 0xC000013A (STATUS_CONTROL_C_EXIT).

Observed local timestamps (UTC+08:00):

2026-08-21 11:49:59
2026-08-21 14:08:33
2026-08-24 18:52:08
2026-08-24 18:52:37
2026-08-24 19:01:48

The affected persisted session contains 236 custom_tool_call records but only 231 custom_tool_call_output records (5 unmatched calls). All five unmatched calls were local exec/test invocations. Once the interrupted records were persisted, resuming that task repeatedly hit the missing-output validation path and restarted app-server, so the thread became effectively unrecoverable.

A useful distinction from a generic native app crash:

no Codex/ChatGPT Application Error 1000 or Application Hang 1002 event;
no Codex/ChatGPT crash dump;
no GPU reset or OOM evidence;
the desktop shell survived/restarted the backend.

This suggests two related hardening opportunities: prevent the Windows command/process path from terminating app-server with a console-control exit, and make session recovery tolerate or repair interrupted custom tool calls instead of fatally exiting on a missing output.

Disclosure: this comment was prepared and posted by Codex at the account owner's request.

williamxhero · 3 days ago

I can confirm the same failure on another Windows machine.

Environment

Codex Desktop MSIX: 26.818.5229.0
Bundled app-server reported by Desktop: 0.149.0-alpha.4.1
Windows 11 Pro 10.0.26200 x64
Python 3.13
Local Windows workspace, not WSL

Reproduction observed

An agent turn executed:

python -m unittest discover -s tests -p "test_router_core.py" -v

The unittest process completed in approximately 4.5 seconds with ordinary Python test failures and thread exceptions. Immediately afterwards, the Desktop app-server exited with:

app_server_connection.closed code=3221225786 signal=null
Codex CLI process exited classifiedAsExpected=false
fatal_error_broadcasted

The command tool call was persisted in the thread transcript, but its corresponding tool output was not. This left a new dangling tool call and caused the resumed turn to be marked interrupted.

A preceding git status --short --branch command in the same turn completed normally and its output was persisted.

Repeatability

The same thread has shown this sequence multiple times:

Start a local unittest command.
Unittest emits output, including ordinary non-zero test results.
The app-server exits with 0xC000013A.
Desktop restarts the app-server.
The transcript contains the command call but no corresponding output.

Repairing the dangling transcript records allowed the thread to resume, but the next execution of the unittest command generated a new dangling call. This indicates that transcript corruption is an aftermath of the app-server termination, not the original cause.

Hook boundary

A normal command produced its expected PostToolUse hook event. The failing unittest command produced no PostToolUse event, indicating that the app-server exited before the tool output was persisted and before post-tool hooks were invoked.

No Ctrl+C, cancellation, or terminal close was initiated manually. No Windows Application Error / WER crash event was recorded for the bundled codex.exe process.

fionasapples · 3 days ago

Fourth independent reproduction, 26.818.5229.0, with three datapoints I don't see in the thread yet: a same-day clean-reinstall control, a varying respawn gap, and a stable standalone-CLI control on the same machine.

Environment

Store package OpenAI.Codex 26.818.5229.0 (x64), Windows 11 Home 10.0.26200, 64 GB RAM
Standalone winget Codex CLI 0.146.1 also installed (relevant below)

Kills observed 2026-08-24 (shell log)

2026-08-24T11:08:21.299Z error [AppServerConnection] Codex CLI process exited classifiedAsExpected=false code=3221225786 signal=null transport=stdio
2026-08-24T15:20:09.425Z error [AppServerConnection] Codex CLI process exited classifiedAsExpected=false code=3221225786 signal=null transport=stdio

Same signature as above: no WER report, no Application Event Log entry, no crash dump, RAM plentiful. Engine-log (logs_2.sqlite) tails match the OP: first kill mid item/commandExecution/outputDelta streaming; second kill 8 s after an item/commandExecution/terminalInteraction event during an active turn. Before the reinstall (below), the same package showed 6 further engine generations in one morning (lifetimes 1–18 min under command-heavy load), including a kill where the replacement engine spawned 7 s later.

New datapoint 1: clean reinstall does not fix it

Between the two kills above I did a full Remove-AppxPackage uninstall and a fresh Store install of the same .5229 build (package data folder recreated from scratch; ~/.codex preserved). First kill on the fresh install came ~16 minutes after relaunch, identical signature. This complements the OP's rule-out list: it is not install/package-state corruption either.

New datapoint 2: respawn gap varies

First kill → respawn in ~1 s (stdio_transport_spawned at 11:08:22.272Z). Second kill → respawn only after 2 m 10 s (15:22:19.916Z), a full outage window rather than a blip.

New datapoint 3: standalone CLI on the same machine is unaffected

As a control, a standalone winget Codex CLI 0.146.1 process ran continuous agent work on the same machine (long-running commands, a subagent, a 6-minute heartbeat test loop) for 5+ hours spanning both desktop kills — zero deaths. This makes machine-level externals (EDR, console tooling, power events) unlikely and points at the desktop bundle's app-server (0.149.0-alpha line) or its command/terminal path specifically.

Aftermath matches the dangling-tool-call reports

The 15:20Z kill orphaned the in-flight call. Every turn attempted on that thread afterwards failed for ~2 minutes (four distinct turn ids, 15:31:41Z–15:33:13Z, including during run_auto_compact{reason=ContextLimit phase=MidTurn}):

ERROR codex_core::util: ...run_turn.prepare_sampling_request_input: Custom tool call output is missing for call id: call_OVqbtpRguOXZtqcrCFmrbAw4

Same shape as the unittest reproduction above and #40400: transcript damage is aftermath, not cause.

Happy to provide fuller shell-log or engine-log extracts for any of these events.

Disclosure: this comment was prepared and posted by Claude at the account owner's request.

fionasapples · 3 days ago

Follow-up to my earlier comment (the 26.818.5229 / Win11 26200 reproduction with the clean-reinstall control). We ran a deeper local-forensics + literature/source review pass on the kill mechanism. Summary of what it supports, with the reasoning available for scrutiny:

1. The kill correlates with command interruption/cleanup, not output volume per se

On this machine, 5 of the day's 7 highest outputDelta-rate seconds (313–974 events/s) were each followed by an app-server death within 7–86 s (4 deaths across ~9 h, so chance placement is implausible, though "high output" and "gets interrupted" are confounded by construction). The killed turns were running batched parallel file reads (Get-Content ... -First N / rg via the exec tool, yield_time_ms set) — precisely the class of child command that hits output caps/timeouts and gets interrupted or torn down. One death followed an item/commandExecution/terminalInteraction event by 8 s.

2. "disconnecting slow connection after outbound queue filled" appears to be a red herring for the crash

That warning comes from the transport's bounded outbound channel (CHANNEL_CAPACITY = 128, try_send → Full → drop that one websocket connection) — the #18203 / #19246 / #37526 lineage. It terminates a single connection and no process. In our incident it preceded death by 20 s but the exit itself still needs a console-control delivery.

3. The exit signature is a console-control self-kill, and the absence of crash artifacts is the fingerprint

0xC000013A with no WER report, no crash dump, and no Event Log entry is what the default console handler produces: an unhandled CTRL_C/CTRL_BREAK/CTRL_CLOSE reaches a process with no handler installed (Rust installs none by default) and the default handler calls ExitProcess(STATUS_CONTROL_C_EXIT) — a clean exit, so no crash reporting fires. On Windows a Ctrl event aimed at a child on a shared (hidden) console broadcasts to every attached process including the sender/parent; same footgun class as MiniZinc/minizinc-python#191, CPython bpo-11361, dotnet/msbuild#4832. The desktop stack's pty layer also performs the FreeConsole → AttachConsole(child) → Ctrl-C console-list dance during ConPTY cleanup (see #25272 for that helper in the wild), which can land the Ctrl-C on the app-server if it is attached at the wrong moment.

4. This maps cleanly onto the version history

PR #35655 (CLI 0.147.0) — "Terminate Windows non-TTY processes on interrupt" — deliberately routes Windows interrupts away from console signaling into the termination callback, and consumes the terminator after a successful interrupt. That is exactly the hazard class above. Consistent with it: a standalone winget CLI 0.146.1 on this same machine ran identical command-heavy work for 5+ hours spanning two desktop deaths with zero exits, while the desktop bundle (app-server 0.149.0-alpha line) died four times in a day. This looks like the #35655-era protection regressed (or is bypassed by the desktop pty path) in the alpha bundle shipped with 26.818.5229.

5. Ruled out locally

Console-host crash class (microsoft/terminal#18209, spontaneous 3221225786 on the 24H2 codebase): zero conhost/OpenConsole/WindowsTerminal crash events on the failing days; Windows Terminal 1.24.11911 (≥ fixed 1.21.2911).
AV/EDR, OOM, job-object kills: wrong exit signatures; 26+ GB RAM free at every death; no Defender operational events.

Cheap diagnostic + hardening suggestions

Install a logging SetConsoleCtrlHandler in the app-server that records which event type (CTRL_C / CTRL_BREAK / CTRL_CLOSE) arrives before exit — one repro then names the delivery path.
Spawn exec children with CREATE_NEW_PROCESS_GROUP | CREATE_NO_WINDOW (or a dedicated ConPTY) so control events can never target the app-server's group; scope any GenerateConsoleCtrlEvent to the child's own group id, never group 0; keep FreeConsole/AttachConsole enumeration out of the app-server process.
On unexpected exit, synthesize an error output for orphaned tool calls so the resumed thread doesn't loop on "Custom tool call output is missing" (per my earlier comment and #40400 / #32653).

Disclosure: this comment was prepared and posted by Claude at the account owner's request.

bmankowitz · 20 hours ago

Still reproducing on Store OpenAI.Codex 26.820.7780.0 (Windows 11 26200). Same exit 3221225786 / 0xC000013A.

[features] unified_exec = false was already pinned. Desktop still persisted PTY write_stdin custom exec calls.

Observed two stages on 2026-08-27:

Overnight: app-server died mid-flight (code=3221225786) while shutting down an MCP client. Electron stayed up. Rollout kept unpaired custom_tool_call records (no matching output).
Next morning: auto-thread/resume of that long-running task plus others. After a few minutes, shared app-server fatal-exited with Custom tool call output is missing for call id: … and code=3221225786. Other open threads died with it.

No WER / AppCrash / Crashpad dump. Isolating the affected JSONL (move out of sessions/, do not back-patch) restored new chats.

This is the #32653 resume-poison path sitting on top of the Windows console-control kill in this issue. Config pin + new chat after a prior quarantine did not prevent it.

Details (sanitized) posted on #32653.