Repository navigation
Windows: app-server killed with STATUS_CONTROL_C_EXIT (0xC000013A) mid command execution; regressed in 26.818.5229 after being fixed post-26.810 #40231
Description
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 areitem/commandExecution/outputDeltaTRACE 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
commandExecutionevents 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.tomlrebuilt to near-stock (and temporarily read-only-locked so the app could not rewrite it)logs_2.sqlitereset (was 763 MB; reproduced with a fresh small DB)- state / queue / memories DBs:
pragma integrity_checkok, 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.
Activity
github-actions commentedon Aug 23, 2026
Potential duplicates detected. Please review them and close your issue if it is a duplicate.
Powered by Codex Action
hauomu commentedon Aug 24, 2026
Independent reproduction here on a second Windows machine, with the same
.5229signature.Environment
OpenAI.Codex 26.818.5229.0Microsoft Windows NT 10.0.26200.0(x64)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:
followed by another occurrence on the restarted app-server:
So this is again
3221225786 == 0xC000013A / STATUS_CONTROL_C_EXIT, withsignal=nullandclassifiedAsExpected=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:
I don't know whether this projection error is causal or merely the last warning emitted before the separate
STATUS_CONTROL_C_EXITtermination, 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.exepath are definitely.5229, while some retained Sentry event metadata still identifies the frontend release ascodex@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 commentedon Aug 24, 2026
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.00xC000013A / STATUS_CONTROL_C_EXITregression.Unfortunately, the Beta channel is also unusable on the same machine.
Stable vs Beta result
For the Beta failure, UAC itself is healthy, both AppX packages report
Status: Ok, the signedcodex-windows-sandbox-setup.exeexists and validates as OpenAI-signed, and the Betacodex.exe app-serverstarts.After repeated Beta setup attempts, however, there is still no
setup_marker.json, nodeny_read_acl_state.json, nosetup_error.json, and noCodexSandbox*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
.5229app-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 commentedon Aug 24, 2026
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-serverrepeatedly exited and was restarted. Relevant sanitized desktop-log sequence:3221225786 == 0xC000013A (STATUS_CONTROL_C_EXIT).Observed local timestamps (UTC+08:00):
The affected persisted session contains 236
custom_tool_callrecords but only 231custom_tool_call_outputrecords (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:
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 commentedon Aug 24, 2026
I can confirm the same failure on another Windows machine.
Environment
26.818.5229.00.149.0-alpha.4.110.0.26200x64Reproduction observed
An agent turn executed:
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:
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 --branchcommand in the same turn completed normally and its output was persisted.Repeatability
The same thread has shown this sequence multiple times:
0xC000013A.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
PostToolUsehook event. The failing unittest command produced noPostToolUseevent, 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.exeprocess.fionasapples commentedon Aug 24, 2026
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
OpenAI.Codex 26.818.5229.0(x64), Windows 11 Home10.0.26200, 64 GB RAMKills observed 2026-08-24 (shell log)
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 miditem/commandExecution/outputDeltastreaming; second kill 8 s after anitem/commandExecution/terminalInteractionevent 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-AppxPackageuninstall and a fresh Store install of the same.5229build (package data folder recreated from scratch;~/.codexpreserved). 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_spawnedat 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}):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 commentedon Aug 24, 2026
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/rgvia the exec tool,yield_time_msset) — precisely the class of child command that hits output caps/timeouts and gets interrupted or torn down. One death followed anitem/commandExecution/terminalInteractionevent 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 theFreeConsole→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
Cheap diagnostic + hardening suggestions
SetConsoleCtrlHandlerin the app-server that records which event type (CTRL_C / CTRL_BREAK / CTRL_CLOSE) arrives before exit — one repro then names the delivery path.CREATE_NEW_PROCESS_GROUP | CREATE_NO_WINDOW(or a dedicated ConPTY) so control events can never target the app-server's group; scope anyGenerateConsoleCtrlEventto the child's own group id, never group 0; keepFreeConsole/AttachConsoleenumeration out of the app-server process.Disclosure: this comment was prepared and posted by Claude at the account owner's request.
bmankowitz commentedon Aug 27, 2026
Still reproducing on Store
OpenAI.Codex26.820.7780.0(Windows 11 26200). Same exit3221225786/0xC000013A.[features] unified_exec = falsewas already pinned. Desktop still persisted PTYwrite_stdincustomexeccalls.Observed two stages on 2026-08-27:
code=3221225786) while shutting down an MCP client. Electron stayed up. Rollout kept unpairedcustom_tool_callrecords (no matching output).thread/resumeof that long-running task plus others. After a few minutes, shared app-server fatal-exited withCustom tool call output is missing for call id: …andcode=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.
Marc111111 commentedon Aug 28, 2026
Confirmed independently on a second Windows machine, and the regression persists in a newer build: OpenAI.Codex 26.825.4187.0.
Environment:
10.0.2620026.825.4187.0Exact shell-log signature:
The active task was subsequently recovered with
latestTurnStatus=interrupted.There was no new Windows WER/Application Event entry for this backend termination. The desktop process survived/recovered, but the active command stopped without a sufficiently visible failure indication.
The most recent warning retained before the termination was:
I am not claiming that warning caused the termination; it was simply the latest preceding backend warning retained in the fatal-error context.
This independently confirms the exact
0xC000013A/classifiedAsExpected=falsesignature and shows that it remains present in26.825.4187.0.willguerin commentedon Sep 1, 2026
Additional independent reproduction on a newer Windows Desktop build, with the same termination signature.
Environment
OpenAI.Codex 26.825.6671.00.151.0-alpha.7.226200.9168, x642.6.3, kernel6.6.87.2-1Observed events
The retained desktop logs contain five unexpected bundled
codex.exeapp-server exits:Every event has the same sequence/signature:
3221225786 == 0xC000013A == STATUS_CONTROL_C_EXIT.The UI presents the generic failure/reload experience. The local app server is then restarted. At least for the final three events, Electron main-process logging continued across the engine death, supporting app-server termination rather than whole-desktop-process termination.
Workload correlation
The failures occurred during substantial concurrent local work in two independent projects (one Windows-native and one WSL-backed). Starting a fresh continuation thread did not eliminate the failures.
Recovery logs marked multiple streaming threads as needing resume during earlier events (six for the first failures, three for another); the final two marked one. This suggests concurrent work amplifies the failure but is not a necessary condition.
A durable Goal-based thread could resume after the UI/app-server recovery. A non-Goal thread could lose its in-flight operation and did not automatically resume.
Resource and OS evidence
A read-only system snapshot during comparable concurrent work did not show aggregate exhaustion:
vmmemWSLabout 2.7 GiBNo correlated Windows Application Error, Application Hang, WER crash, resource-exhaustion event, GPU/display reset, WSL failure, or backend HTTP 5xx/connection-reset sequence was found.
There was noisy WSL Git-watcher
EISDIRactivity around the first two failures, but none around the final three, so it does not explain the recurring exit signature.Version correlation
Within the retained 16-day desktop log window, there were no unexpected app-server exits before the current
0.151.0-alpha.7.2engine family and five afterward. This is correlation rather than proof of regression, but it extends the sameSTATUS_CONTROL_C_EXITfailure through Desktop26.825.6671.0.Raw logs, absolute paths, project names, thread IDs, and transcripts are intentionally omitted. Sanitized extracts can be provided through a secure support channel if requested.
MoonlightEnola commentedon Sep 11, 2026
Additional evidence: kernel-level (Sysmon) capture of the kill, still present on 26.903.9818.0
Same signature as reported here. Adding forensics that the existing reports in this issue don't have:
a kernel-level (Sysmon) record of the kill itself, plus 1 Hz process sampling.
Environment (paths/usernames redacted)
10.0.26200, x6426.903.9818.0(installed 09-10 17:34 local)codex-cli 0.153.426.903.9818.0update landed, i.e. the 26.818 regression is still present in 26.903.All kill events observed on this machine (
Codex CLI process exited classifiedAsExpected=false)Sysmon capture of one kill (09-11 15:21:14 local)
codex.exe) terminatedapp_server_connection.closed closeCode=3221225786Codex CLI process exited classifiedAsExpected=false code=3221225786fatal_error_broadcastedcause=start_process(auto-restart)Finding 1 — no process ever obtained
PROCESS_TERMINATEon the app-server before it died.Sysmon
ProcessAccess(ID 10) was enabled for the whole session, filtered onTargetImageending withcodex.exe.In the 2 s before the kill every access was query-only (
0x1000,0x1410,0x101000).The only accesses carrying the terminate bit appear 0.2–0.3 s AFTER the process had already died:
(the parent's call trace at 15:21:14.808 lands entirely inside
chrome.dll— Chromium's process-management path)=> This is exactly what a console control event looks like: it is not delivered through
OpenProcess,so it leaves no
ProcessAccessrecord at all. It is not consistent withOpenProcess(PROCESS_TERMINATE)+TerminateProcess.Finding 2 — the console was not closed (rules out
CTRL_CLOSE_EVENT)1 Hz sampling of the
conhost.exeprocess count around the kill:A closed console would have taken its
conhostwith it. It did not.=> leaves
CTRL_C_EVENT/CTRL_BREAK_EVENT(note:taskkillwithout/Falso delivers this class of signal).Finding 3 — no resource exhaustion
1 Hz sampling of the app-server over the last 10 s of its life:
Handles +6, threads +1, working set +1.1 MB over 10 s. No leak, no handle exhaustion, no memory pressure.
Finding 4 — the desktop spawn path was isolated and did not reproduce the kill (single sample)
I launched the same kind of workload (
codex execrunning a read-only git/python loop) through a small launcher that calledCreateProcesswithCREATE_NEW_CONSOLE | CREATE_BREAKAWAY_FROM_JOB | CREATE_NEW_PROCESS_GROUP, closed the returned processhandle immediately, and waited on a reopened handle carrying only
SYNCHRONIZE | PROCESS_QUERY_LIMITED_INFORMATION(i.e. the parent provably had no terminate right).
Caveats, stated plainly: this is a single sample, and
codex execis a different runtime shape from the desktopapp-server (no MCP servers, no browser-use session, no UI event stream). So this does not prove the desktop spawn path
is the only trigger. But the one structural difference that stands out is
CREATE_NEW_PROCESS_GROUP.Related
serenorg/seren-acp-codex#6— "Windows Ctrl+C kills Codex sidecar (missing CREATE_NEW_PROCESS_GROUP)".taskkill.exein a repeating ~20–30 s cycle around the deaths.taskkillwithout/Fis exactly the kind of thing that raises a console control event instead of callingTerminateProcess.Suggestion
Regardless of the remaining root cause: spawning the app-server with
CREATE_NEW_PROCESS_GROUP(and not sharing the parent'sconsole) would make it immune to console control events aimed at a command's process group — a cheap, targeted mitigation
that also matches the only isolation test that survived here.
Happy to run any additional instrumented test you'd like (Sysmon is now also logging every
taskkill.exespawn and everychild of the desktop process, so the next occurrence will show whether the
taskkillcleanup cycle really fires at the kill).sergdz commentedon Sep 12, 2026
The same backend failure still reproduces on Windows Desktop 26.908.4834.0 with bundled app-server 0.154.0-alpha.6.2: three unexpected exits after the update with code 3221225786 = 0xC000013A / STATUS_CONTROL_C_EXIT. The retained window contains 25 identical exits before the update.
Separately, after the update, renderer/GPU children were killed and Windows recorded a top-level ChatGPT.exe Application Hang 1002 / WER MoAppHang; the whole desktop app closed and restarted. New issue: #45020
I am not claiming that the app-server exit is proven to cause the Desktop hang; Windows recorded no exception code for the main process.
willguerin commentedon Sep 23, 2026
Follow-up from my Windows machine, at my request, with a different failure signature from the
0xC000013Aapp-server exits reported above. I am adding it here because it occurred during substantial concurrent Codex work; I am not claiming it has the same root cause.On 2026-09-23, before the subsequent update, the running Store package was OpenAI.Codex 26.917.6896.0 (bundled app-server
0.155.0-alpha.16). I perceived a Desktop UI freeze sometime between 13:45 and 21:00 Europe/Madrid. Retained logs show earlierthread/startrequest timeouts at 11:58–12:49 UTC, then a clear stall beginning around 18:31 UTC (20:31 Madrid):[AppServerConnection] app_server_client_request_queue_rejectedrepeatedly reportedinFlightRequestCount=6andreason=queue-expired. Affected methods includedthread/read,thread/resume,thread/list,config/read, andturn/steer.thread_hydrationspans failed withreason=timeoutafter approximately 234 and 247 seconds. Laterthread/resumeattempts timed out after 240 and 480 seconds.App server request expired while queued.The Desktop was still logging navigation, and the app-server still received some requests. I found no unexpected app-server exit /
3221225786signature, Codex WER/Application Error entry, or Crashpad dump for this incident. This points to a request/queue stall rather than proving a renderer crash or full process termination; what held the six in-flight slots is unknown.The WSL Git watcher emitted roughly 58,000
EISDIRwarnings that day, including during the stall (possibly relevant load, not established as causal; see #33764). Remote-control/model-refresh timeouts also co-occurred. The later update to 26.917.8451.0 happened after this incident, so it is not a test of that build.Could maintainers check what kept those six requests in flight, and whether a stalled request can starve thread hydration/steering under concurrent workloads? Sanitized log excerpts can be provided.
willguerin commentedon Sep 24, 2026
Post-update recurrence of the request-queue stall described in my Sept 23 comment. This is still not a confirmed recurrence of the
0xC000013Aprocess-exit signature.On 2026-09-24, the running Windows Store Desktop build was OpenAI.Codex 26.917.8451.0. The UI became unresponsive again, and I closed and reopened it. Retained Desktop logs show queue saturation starting about 07:26 UTC (09:26 Europe/Madrid):
app_server_client_request_queue_rejectedreportedinFlightRequestCount=5, then6, withreason=queue-expired. Config, app/plugin, model, thread-list, and thread-history requests expired after roughly 30–60 seconds. The renderer still logged successful navigation and some app-server responses during this period.At 07:28:21 UTC, the old instance logged
Stopping app-server transportwithcause=stop_processduring my manual close; a fresh instance launched seconds later. I found no unexpected app-server exit /3221225786, Windows Application Error/Hang or relevant System event, or Crashpad dump for this window. The WSL Git watcher continued to emit roughly 106EISDIRwarnings/minute, but its causal role is unknown. A post-relaunch snapshot showed about 29 GB of 64 GB physical RAM free; this is not a measurement during the freeze.This natural-use recurrence shows that 26.917.8451 did not eliminate the queue-stall behavior. It does not establish that concurrent heavy threads, WSL, or a particular repository caused it. The unresolved question remains which requests held the in-flight slots and why routine requests could not progress. Sanitized log excerpts are available.
yougaset commentedon Sep 25, 2026
Reproduced again on 2026-09-25 on a substantially newer Desktop build, with additional source-level evidence.
Environment
10.0.2620026.917.9434.0(MSIX)codex-cli 0.155.0-alpha.16.40.155.1Reproduction / control
The same local repository, same conda environment, and same pytest command were tested through both paths:
codex exec: succeeded in 14415 ms, 4 passedDesktop log evidence
On the third failure, the Desktop log recorded:
So the in-flight tool call is interrupted by an app-server exit with
3221225786 == 0xC000013A == STATUS_CONTROL_C_EXIT, and Desktop immediately spawns a replacement backend.I found at least 8 non-normal backend exits on the same day (including this exact code and a few explicit hard-kill/debugger codes), so this is not a one-off process restart.
Source-level findings from the exact bundled tag
I inspected
openai/codextagrust-v0.155.0-alpha.16.4, matching the bundled backend exactly.The unified exec output collector itself is bounded:
process_manager.rs::collect_output_until_deadline()tokio::select!with a deadlineMAX_YIELD_TIME_MS = 30_000This rules out “the command-output collection loop waits forever” as the direct cause of a multi-minute UI freeze.
Relevant awaits that are not wrapped in their own deadline include:
open_session_with_sandbox(...).awaitinteraction_lock().lock_owned().awaitrequest_approval(...).awaitHowever, in the observed incident the backend process itself is terminated, so all in-process futures disappear with it.
Missing custom-tool outputs appear to be a consequence, not the process-kill cause:
context_manager/normalize.rsdetects aCustomToolCallwithout matching output and inserts an"aborted"output.error_or_panic()only logs in release builds; it does not panic there.This matches the observed sequence:
Additional narrowing
The Windows PTY/job path in this tag uses Job Objects /
TerminateJobObject; I did not findGenerateConsoleCtrlEventin the repository. So I still cannot identify the sender of the console control event statically.A plausible remaining hypothesis is that a child shell/conda process and the packaged
codex.exeshare a hidden console/process group and a console control event intended for a child reaches the app-server as well, but this part is not proven yet.The main new point is that the original
0xC000013Afailure signature from this issue is still reproducible on 26.917.9434.0, and when it happens during a tool call the Desktop recovery path can leave the active turn permanently stuck.If useful, I can capture a minidump on the next reproduction to identify the exact termination path / console-event source.
willguerin commentedon Sep 29, 2026
Follow-up to my earlier reports: I have another unexpected bundled app-server exit, this time with only one active Codex working thread. This is distinct from the September 23–24 request-queue stalls I reported, where the diagnostic review did not find an unexpected process exit.
Feedback ID:
01a0585f-ac70-72c1-abd3-0fc6b22b03b8Incident time: approximately 2026-09-29 00:01:54 UTC, or 02:01:54 CEST (Europe/Madrid).
Environment
26.924.2738.0.0.158.0-alpha.2.1.0.152.0. This is not the runtime that exited.gpt-6-sol, High effort.I was running only one working thread. The recovery session also reported no other active project-writing Codex session or repository-writing process.
Diagnostic findings
A read-only diagnostic pass over the local desktop and session logs reports this sequence:
app_server_connection.closed.Codex CLI process exitedwith code3221225786, matching the decimal exit code in this issue.The desktop itself remained running. The affected session has no result for its final tool call and no normal completion event. The diagnostic pass found no nearby recorded cancellation or context-compaction event and no pending approval or input request.
The UI did show automatic context compaction earlier in the run, but Codex performed several operations afterward. I am not presenting that earlier compaction as the cause of the process exit. Nearby OAuth and usage-stream warnings also do not establish causation.
Interrupted operation
The final tool call started
pyteston two local unit-test files with--maxfail=1, piping output to a local log. It collected 38 tests and wrote progress through 89%, but there is no final test summary or exit code. No matching test process survived when the diagnostic pass checked. The diagnostic did not rerun the tests.Before the interruption, static checks and frontend TypeScript compilation exited 0, and a separate focused unit-test group completed with 83 passed. The local repository remained clean at its preserved checkpoint. Recovery is paused, and the incomplete test group is not being counted as passed.
What remains unknown
The evidence supports an unexpected bundled app-server process exit and connection loss, rather than simply an assistant deciding to stop. The underlying cause remains undetermined. There is no evidence in this diagnostic implicating another Codex working session, and I do not know whether this shares the cause of my earlier concurrent-workload failures or the later queue stalls.
Please correlate the feedback ID with the app-server exit at the UTC time above and investigate what triggered the termination during command execution. The practical issue is that the single-thread precaution did not prevent this occurrence, and the run stopped without reporting the interrupted command's outcome.
Private repository names, absolute paths, raw logs, and unrelated session identifiers are omitted from this public comment. The diagnostic report identifies local desktop-log and partial test-output evidence for any further requested investigation.