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

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

• #35210
• #35311

Powered by Codex Action

Additional single-thread reproduction (2026-07-29 KST)

This issue reproduced again with only one Codex workload active, so concurrent tasks are not required.

Environment remains Codex desktop 26.721.4979.0 on Windows 11 x64.

Timeline

Times below are UTC (KST = UTC+9).

2026-07-28T16:30:59.911Z ERROR write_stdin failed: Unknown process id 86678
2026-07-28T16:31:35Z       A new pytest process (session 65982) started
2026-07-28T16:33:14Z       The test run had reached approximately 70%
2026-07-28T16:33:14.697Z   app_server_connection.closed code=3221225786
2026-07-28T16:33:14.698Z   Codex CLI process exited classifiedAsExpected=false
2026-07-28T16:33:48.982Z   Codex CLI initialized after automatic restart
2026-07-28T16:33:50.390Z   app_server_restart_recovery_done resumedCurrentConversation=true

The recovered thread was marked with its latest turn status as interrupted; the running test result was lost.

The Unknown process id 86678 was the most recent router error recorded in the app-server close reason. It occurred after attempting to poll an already-finished long-running command. A different, newly started process was active when the app-server exited. This is correlation, not proof that the stale process poll caused the exit, but it provides a narrower reproduction path:

1. Run a long shell/test process and poll it with write_stdin.
2. Let that process finish or disappear.
3. Poll the stale process ID and receive Unknown process id.
4. Start another long shell/test process and continue polling.
5. The Codex CLI/app-server exits unexpectedly while the new process is still active.

Memory and transcript size

Memory pressure was again ruled out at the failure time:

• Physical memory used: about 14.9%
• Physical memory free: about 108.7 GB
• Commit used: about 13.7%
• Codex private memory: about 0.20 GB

The affected thread transcript was approximately 20.57 MiB / 4,577 lines, far below the previously observed pathological transcript sizes.

A later app restart also logged the already reported secondary lifecycle sequence:

IAB_LIFECYCLE route window is not live
IpcRouter Socket error errorCode=EPIPE errorMessage="write EPIPE"
Stopping app-server transport

The generated project artifacts remained intact, but final verification was interrupted. Please investigate whether stale unified-exec process polling or app-server recovery on Windows can terminate the host process instead of returning an isolated tool error.

怎么解决，我也是

Root cause narrowed: descendant process termination can take down the Windows app-server

I now have a deterministic local reproducer and a mitigation that removes the crash.

Stronger reproduction

Environment is unchanged:

• Codex Desktop: 26.721.4979.0
• app-server: 0.146.0-alpha.3.1
• Windows 11 x64
• fatal exit: 3221225786 / 0xC000013A

The failing workload was a Python/pytest suite that tests file-lock recovery with multiple subprocesses. The application code under test contained this Unix-style PID liveness probe:

os.kill(pid, 0)

Python's Windows documentation states that, except for CTRL_C_EVENT and CTRL_BREAK_EVENT, os.kill uses TerminateProcess; signal 0 is therefore destructive on Windows rather than a read-only existence probe:
https://docs.python.org/3/library/os.html#os.kill

This project bug caused a descendant/sibling test process to be terminated. However, the Codex failure was not isolated to the tool invocation: the main Codex app-server also exited with 0xC000013A, all desktop tasks were interrupted, and the active turn was left without a tool result.

I reproduced the same whole-app failure:

1. In the original long thread.
2. Again after restarting with only three MCP servers, all available (3/3; no unavailable server).
3. In a separate small diagnostic thread.
4. With the pytest child created using CREATE_NEW_PROCESS_GROUP; Codex still terminated.

Two affected full-suite tool calls were persisted without outputs. Desktop logs recorded:

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

The crash dialog again promoted an unrelated last WARN (for example, plugin defaultPrompt validation) as the apparent cause.

Thread corruption ruled out

The original rollout was validated independently:

• 81,585,612 bytes
• 35,892 JSONL records
• 0 JSON parse errors
• 5 unmatched tool calls, all explainable as residue from interrupted app-server exits

Therefore malformed rollout JSON was not the direct trigger in this reproduction.

Local mitigation and A/B result

I changed the Windows branch to bypass os.kill completely and use a read-only Win32 process query (OpenProcess + GetExitCodeProcess).

A regression test now fails if the Windows path calls os.kill.

Before the fix:

• The exact full test file repeatedly terminated Codex Desktop/app-server.

After the fix:

python -m pytest tests/test_instagram_graph_io.py -q
.................................... [100%]
36 passed in 1.95s

The app-server remained alive, the original thread resumed, and subsequent tool executions completed.

Why this still appears to be a Codex Windows isolation bug

The project code's destructive Windows PID probe was a valid trigger that needed fixing. But a descendant tool process terminating another descendant should fail that tool or process tree only. It should not terminate the main Desktop app-server or every unrelated task.

Please investigate Windows unified-exec process-tree/job-object/console cleanup when a descendant process is terminated, including whether cleanup propagates a control event to the app-server. A useful regression test would run a tool that spawns two children, forcibly terminates one child, and verifies that the app-server and unrelated tasks remain alive.

Related reports with the same exit code and misleading last-WARN diagnostics include #21761.

Independent reproduction on a newer Windows Desktop build

I can independently reproduce the same failure mode on a newer Codex Desktop build, with the same project-side trigger described in the root-cause comment above.

Environment

• Windows x64, native PowerShell
• Codex Desktop MSIX package: 26.727.6591.0
• Desktop client reported in app-server requests: 26.727.51351
• Bundled session runtime: 0.146.0-alpha.9.2

Trigger and timeline

A newly added Python unittest suite exercises a project lock's PID-liveness check:

os.kill(pid, 0)

The suite was invoked through Desktop custom exec three times:

2026-08-03T08:00:58Z  full unittest module
2026-08-03T09:22:08Z  focused set including the concurrent-lock test
2026-08-03T09:29:54Z  full unittest module again

Each invocation was persisted as a completed custom_tool_call, but no matching custom_tool_call_output was written. The corresponding codex.exe app-server generation disappeared within roughly 2–3 seconds and Desktop started a replacement process.

The outer ChatGPT.exe process remained alive and responsive throughout. I found:

• no matching Windows Application Error / WER event;
• no Crashpad dump;
• no Resource Exhaustion event 2004;
• more than 13 GB of physical memory free.

This matches the issue's distinction: the project has a real Windows bug that should be fixed, but termination/control events from a tool descendant should not take down the shared Desktop app-server.

Persisted task state after recovery

The affected rollout is valid JSONL but now has three unmatched custom tool calls. Reopening/resuming it logs:

Custom tool call output is missing for call id: <redacted>

This is also closely related to #32653. The thread can sometimes start another turn after restart, but running the same suite again repeats the app-server exit and adds another unmatched call.

Questions for maintainers

1. Is there a supported recovery path for an existing Desktop task containing interrupted/unmatched custom tool calls, without manually editing or back-patching the rollout JSONL?
2. Should users archive the affected task and continue in a fresh task, or is there a supported way to quarantine/mark the interrupted turn as failed and safely resume the same task?
3. Is Windows descendant-process / console-control isolation expected to be fixed in a build newer than 26.727.6591.0, or is this still an open app-server/unified-exec issue?

For now I am avoiding the affected task and the triggering test command. I can provide sanitized process-span and SQLite log excerpts if useful.