[Windows][26.908.9136.0] Codex Desktop MoAppHang twice after restoring in-app browser tabs and visualizations

Summary

Codex Desktop for Windows became completely unresponsive and Windows closed its ChatGPT.exe host twice within 27 minutes. These were confirmed application hangs, not merely a chat-page refresh, a Codex CLI restart, or a Windows reboot. Both incidents involved the same existing thread's persisted in-app browser sidebar tabs and inline visualizations.

The shared rendering path is a strong correlation, not a proven root cause. In particular, some renderer reason=killed events may be consequences of Windows closing the unresponsive app. I am reporting the precise timing so the desktop team can investigate the main-thread/GPU/webview lifecycle.

Environment

• Windows 11 Home, build 26200, x64
• Microsoft Store package: OpenAI.Codex 26.908.9136.0
• Package deployment completed at 2026-09-15 15:51:28 UTC+8, hours before the hangs. No package deployment occurred at either hang time.
• WER identifies the package as OpenAI.Codex_26.908.9136.0_x64__2p2nqsd0c76g0 and the executable as ChatGPT.exe version 152.0.7977.83.

Sanitized timeline (2026-09-15, UTC+8)

Hang 1

• 20:06:07 and 20:06:14: the desktop log records two in-app browser sidebar tabs opening for the same existing thread. One sidebar webview is a local figure page on localhost:8000.
• 20:06:37.643: browser sidebar render process gone ... reason=killed.
• 20:06:37.654: inline visualization sandbox render_process_gone ... reason=killed.
• 20:06:37.748: Recoverable Chromium child process gone ... processType=GPU reason=killed.
• 20:06:38: Windows Application Hang event 1002 says ChatGPT.exe stopped interacting and was closed; WER records MoAppHang, report ID 5d6ad2fb-fa68-4a9b-9688-a1e7c613695e.

Hang 2

• 20:32:43: after the app was relaunched, the same existing thread restored six in-app browser sidebar tabs.
• 20:33:38-20:33:39: inline visualization guests attached.
• 20:33:41.177: Chromium GPU child process gone, reason=killed.
• 20:33:52.216-20:33:52.277: six sidebar renderer processes for that thread and an inline visualization renderer were reported gone, reason=killed.
• 20:33:53: Windows Application Hang event 1002 and WER MoAppHang; report ID 46c9d12e-47ec-4d51-a527-fdab04614954.

The GPU-child termination in the second incident precedes the Windows hang record by about 12 seconds. The first incident's renderer/GPU termination is essentially simultaneous with the hang record, so it does not establish event direction.

Checks and impact

• No matching Windows System display-driver reset, WHEA/Kernel-Power crash, unexpected shutdown, or Resource Exhaustion Detector event in the 20:00-20:40 window.
• The machine did not reboot; the last OS boot was earlier that morning.
• The user experiences repeated whole-window freezes/closes and interruption of active work. Reopening the app restored more browser sidebar tabs before the second hang.
• A separate local session-history index failure happened the following day after an assistant manually rewrote a live JSONL file. That later event cannot explain these earlier hangs and is tracked separately in #45929.

Expected behavior

Restoring persisted in-app browser tabs or inline visualizations must not block the desktop host until Windows kills it. A failed GPU or webview child should be isolated or recovered without freezing the entire app. If problematic tabs cannot be restored safely, the app should offer a way to reopen without restoring them.

Reproduction status and privacy

The hangs occurred twice with the same browser-heavy existing thread, but a minimal deterministic reproduction has not been established. Related but not identical reports include #40349 and #32040.

Raw desktop logs, session contents, tab URLs, local file paths, and WER dumps are not posted publicly because they can contain private project and browsing data. Sanitized excerpts or additional diagnostics can be supplied through an appropriate private channel. Please prioritize investigation of the Windows desktop hang path.

The report names no repository files or tests. Start by tracing persisted in-app browser sidebar tab and inline visualization restoration from the Windows Application Hang 1002 timeline, then establish a minimal reproduction; done means restoration no longer freezes or closes the host and failed child processes are isolated or recoverable.