Windows Codex Desktop BusyHang when opening thread mini window / popout (thread-overlay)

What version of the Codex App are you using (From “About Codex” dialog)?

Windows Store package: 26.429.3425.0

Extracted app bundle metadata:

• version: 26.429.30905
• codexBuildNumber: 2345
• codexBuildFlavor: prod

The public Windows update metadata at https://persistent.oaistatic.com/codex-app-prod/windows-store-update.json currently reports buildVersion: 26.429.3425.0, so this appears to reproduce on the current Windows Store build.

What subscription do you have?

ChatGPT plan user

What platform is your computer?

Windows, x64, Codex Desktop installed from Microsoft Store.

What issue are you seeing?

Opening a thread mini window / popout can make Codex Desktop freeze for around 10 seconds or longer. During the freeze, the whole desktop can become sluggish enough that the mouse cursor visibly stutters.

The freeze is reproducible from the mini-window path. Local crash/hang investigation points to Codex's thread-overlay route / main-process handling, not WSL, Hyper-V, Git, PowerShell, or a third-party Codex++ injected copy.

The active hung process was the Store app executable:

C:\Program Files\WindowsApps\OpenAI.Codex_26.429.3425.0_x64__2p2nqsd0c76g0\app\Codex.exe

What steps can reproduce the bug?

1. Open Codex Desktop on Windows.
2. Open a thread.
3. Use the thread action to open the mini window / popout.
4. Observe Codex becoming unresponsive; in my repro, Windows desktop input also became visibly stuttery.

What is the expected behavior?

Opening a thread mini window / popout should not block Codex's main browser process or cause system-wide input/UI stutter.

What happened instead?

The Codex main window became non-responsive. A monitor captured Responding=false twice during one repro:

{"type":"hang_detected","responding":false,"dump_index":1,"pid":29820,"ts":"2026-05-04T02:45:00.8033304+09:00"}
{"type":"dump_completed","pid":29820,"ts":"2026-05-04T02:45:23.5900302+09:00","seconds":22.787,"bytes":1430654688,"exit_code":0}
{"type":"hang_detected","responding":false,"dump_index":2,"pid":29820,"ts":"2026-05-04T02:45:29.4111447+09:00"}
{"type":"dump_completed","pid":29820,"ts":"2026-05-04T02:45:33.4533299+09:00","seconds":4.042,"bytes":1481817792,"exit_code":0}

Windows Error Reporting logged an AppHangTransient at the same time:

TimeCreated: 2026-05-04 02:45:34
Provider: Windows Error Reporting
Event: AppHangTransient
P1: Codex.exe
P2: 2345.0.0.0

Dump analysis summary

I captured two full-memory user dumps of the same hung Codex.exe process and analyzed them with WinDbg/cdb using:

.symfix; .reload; !analyze -hang; !runaway; ~* k; q

Both dumps identify the hung process as Codex.exe and the main thread as CrBrowserMain.

First dump:

PROCESS_NAME: Codex.exe
FAILURE_BUCKET_ID: APPLICATION_HANG_cfffffff_Codex.exe!Unknown
Thread 0: CrBrowserMain
ntdll!NtWaitForAlertByThreadId
KERNELBASE!SleepConditionVariableSRW
Codex!node::Buffer::New
Codex!v8::Function::Call
Codex!node::CallbackScope::CallbackScope
Codex!node::EmitAsyncDestroy
Codex!node::PromiseRejectCallback
Codex!uv_pipe_connect2
Codex!uv_run
Codex!node::loader::ModuleWrap::SelfSize

Second dump:

PROCESS_NAME: Codex.exe
FAILURE_BUCKET_ID: APPLICATION_HANG_BusyHang_cfffffff_Codex.exe!Unknown
Thread 0: CrBrowserMain
Codex!Cr_z_crc32+0x6ce253
Codex!v8::internal::compiler::CompilationDependencies::FieldTypeDependencyOffTheRecord
Codex!v8::Function::Call
Codex!node::CallbackScope::CallbackScope
Codex!node::EmitAsyncDestroy
Codex!node::PromiseRejectCallback
Codex!uv_pipe_connect2
Codex!uv_run
Codex!node::loader::ModuleWrap::SelfSize

This looks like a main-process Electron/Chromium/V8/Node/libuv busy hang during the mini-window path rather than an external shell, WSL, Git, or PowerShell issue.

Evidence pointing to thread-overlay

The full-memory dumps contain active thread-overlay routes, for example:

app://-/index.html?initialRoute=%2Fthread-overlay%2F...&hostId=local

The extracted production main bundle contains the relevant IPC/main-process path:

open-thread-overlay -> this.threadOverlayManager.open(...)
thread-overlay-set-always-on-top -> this.threadOverlayManager.setAlwaysOnTop(...)

Local extracted code shows threadOverlayManager.open() creating/syncing/positioning the overlay window around the mini-window route.

Related issues

This appears related to the broader Windows desktop freeze report and mini-window/popout issues, but with a more specific repro and dump evidence:

• #16374: Windows shell/UI freeze associated with Codex activity
• #16180 / #15162: Windows popout window issues
• #18311: macOS mini-window/thread-overlay route issue

Additional notes

• I verified the active hung process path was the official Store app path under C:\Program Files\WindowsApps\..., not a locally modified Codex++ copy.
• I do have the full dump analysis text files and WER/dump monitor logs available if maintainers want specific excerpts or a preferred diagnostic format.
• I avoided attaching full dumps directly because they may contain private local memory/session data.