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

Reproduce the concurrent-task failure on Windows and start with the logged sequence from app-server restart through IAB_LIFECYCLE window removal, EPIPE, and transport shutdown. Trace the recovery, renderer/window lifecycle, browser-session cleanup, and IPC unregister paths; done means a failed task or connection does not terminate the desktop host or interrupt unrelated tasks.

Summary

Since updating the Windows Codex desktop app to 26.721.4979.0, concurrent or high-load tasks can cause the Codex app-server connection to fail. The automatic recovery appears to succeed briefly, but the desktop window then disappears and the entire app terminates, interrupting every active task.

This is a regression for this machine: similar concurrent workloads worked before the recent update.

Related exact-version report: #35311. The trigger here is not limited to in-app Browser use; it also occurred with PDF test execution and an Android Gradle build running concurrently.

Environment

• Codex desktop: 26.721.4979.0, x64 MSIX
• OS: Windows 11 Home, 10.0.26200, x64
• CPU: Intel Core i9-12900K
• RAM: 127.7 GB
• Package update timeline:
  • 26.721.3404.0 -> 26.721.3996.0 on 2026-07-24
  • 26.721.3996.0 -> 26.721.4979.0 on 2026-07-25
• Repeated failures observed on 2026-07-28 KST

Reproduction patterns observed

Pattern A

1. Start two separate, relatively small Codex tasks.
2. Task 1 runs a full PDF regression/test suite.
3. Task 2 runs an Android Gradle AAB build.
4. Continue working in another Codex task.
5. The app-server connection fails, recovery starts, and the entire desktop app terminates.

Pattern B

1. Run an Android browser/DOM inspection task.
2. In parallel, run an unrelated test/discovery task.
3. Codex displays the Windows “ChatGPT stopped unexpectedly” screen or exits/restarts.

The issue has also recurred after moving work from older large threads into new small handoff threads.

Expected behavior

A failed tool, task, or app-server request should be isolated to that task. The desktop host should remain alive, and other tasks should continue running.

Actual behavior

The local app-server fails, the desktop recovery path briefly reconnects, then the main window lifecycle disappears and IPC breaks. All concurrent tasks are interrupted.

Relevant log sequence

Times below are UTC; local time is KST (UTC+9).

2026-07-28T14:48:49Z WARN stream disconnected - retrying sampling request
sampling_error="stream disconnected before completion: failed to send websocket request: Connection closed normally"

connection-failed code=3221225786 signal=null

2026-07-28T14:51:29Z AppServerConnection Restart requested
2026-07-28T14:51:33Z app_server_restart_recovery_done resumedCurrentConversation=true
2026-07-28T14:51:37Z IAB_LIFECYCLE route window is not live
2026-07-28T14:51:37Z IpcRouter Socket error errorCode=EPIPE errorMessage="write EPIPE"
2026-07-28T14:51:37Z Stopping app-server transport

A separate failure at approximately 2026-07-28 22:58:52 KST ended with the same IAB_LIFECYCLE window removal and EPIPE sequence.

Memory pressure ruled out for these failures

An external passive monitor recorded system memory every ~10 seconds. It never terminates Codex or changes process state.

For the 23:51 KST failure:

• 23:48:46: physical memory 16.40%, commit 18.62%
• 23:51:34: physical memory 20.63%, commit 21.48%
• More than 100 GB of physical RAM remained available

For the earlier 22:58 failure, physical memory was about 14–15% and commit was about 14%.

There was no Windows Resource Exhaustion event 2004 around the failures. Recent task transcripts were also small (roughly 1–3 MiB) and had balanced tool-call/tool-output records, so this is not the previously observed very-large-transcript/compaction case.

Additional observations

• The process exit/recovery failure leaves some child workloads, such as Gradle/Kotlin daemons, alive after the desktop app is gone.
• No matching Windows Error Reporting crash entry was produced for the observed termination.
• Reopening interrupted tasks can retrigger the app-wide failure.
• Raw task transcripts are not attached because they may contain private project content. Sanitized desktop log excerpts and a screenshot can be provided privately to OpenAI support.

Please investigate the Windows app-server recovery and renderer/window lifecycle path in 26.721.4979.0, especially the interaction between a failed sampling/WebSocket stream, app-server restart, browser-session window cleanup, and IPC client unregister/EPIPE handling.