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

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):

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.

Reproduce the failure on Windows by running local shell commands through the desktop app-server, then compare shell logs under %LOCALAPPDATA%\Codex\Logs... with the final item/commandExecution/outputDelta rows in logs_2.sqlite. Focus on the engine's handling of console control events during command-output streaming. Done means command-executing sessions no longer terminate with STATUS_CONTROL_C_EXIT while chat-only sessions remain stable.