Windows Desktop freezes briefly when switching into browser-use-associated thread; IAB/sidebar starts during thread switch

Summary

Codex Desktop on Windows intermittently becomes unresponsive / shows "Not Responding" for a few seconds when switching into a specific existing thread. The freeze can happen immediately after clicking the thread, before typing anything. It is not consistently tied to an active model turn; one capture shows no inflight turns and no active browser-use turn routes, while the Desktop UI still considered completed thread state to be streaming.

The strongest correlation in the local evidence is that switching into the affected thread triggers the built-in IAB/browser sidebar lifecycle path (browser_use_iab_backend_startup_started) and thread resume/session setup. This appears to be a Desktop app UI/session-state issue rather than normal model latency.

Environment

• App: Codex Desktop for Windows, Microsoft Store install
• Package: OpenAI.Codex_26.519.11010.0_x64__2p2nqsd0c76g0
• Desktop release from process metadata/logs: 26.519.81530
• Codex.exe file version: 3178
• OS: Windows 11 Home 25H2, build 26200.8457, 64-bit
• Memory during capture: 31.7 GB total, about 15 GB free
• Config: model = "gpt-5.5", model_reasoning_effort = "xhigh"

winget upgrade --name Codex reported no available upgrade.

What happens

1. Codex is open on Windows.
2. User switches/clicks into an existing thread whose Desktop logs show browser/sidebar lifecycle state during thread entry.
3. Codex briefly freezes and Windows may show "Not Responding".
4. The freeze is sometimes too brief to produce a new Windows AppHangTransient, but it is visible in the UI.

Expected behavior

Switching threads should remain responsive. Re-entering a previous thread should not synchronously block the Desktop UI while browser/sidebar/session state is rebound or while stale streaming state is reconciled.

Evidence

Capture A: no inflight turns, but stale streaming state and IAB startup on thread switch

Captured locally at 2026-05-29T07:49:24-05:00.

Windows had earlier Codex AppHangTransient events:

TimeCreated : 5/29/2026 7:43:44 AM
Event Name  : AppHangTransient
P1          : Codex.exe

TimeCreated : 5/29/2026 7:37:59 AM
Event Name  : AppHangTransient
P1          : Codex.exe

App state around the reproduction showed no active turn work, but thread state still marked as streaming:

thread_count_active: 2
thread_count_streaming_owner: 2
thread_count_streaming_with_active_runtime: 0
thread_count_streaming_without_active_runtime: 2
inflight_turn_count: 0
browser_use_active_turn_route_count: 0

Immediately after clicking into the affected thread:

07:48:45.589 | [browser-session-registry] browser_use_iab_backend_startup_started backend=iab platform=win32 release=26.519.81530 routeKey=1:<thread-id>
07:48:45.593 | [browser-use-native-pipe-server] browser-use native pipe listening pipePath=\\.\pipe\codex-browser-use-...
07:48:45.593 | [browser-session-registry] browser_use_iab_backend_startup_ready backend=iab ...
07:48:48.961 | [electron-message-handler] maybe_resume_success ... latestTurnStatus=completed markedStreaming=true turnCount=30

The important part is latestTurnStatus=completed markedStreaming=true plus no active runtime/inflight turn. That looks like stale streaming/session state being reconciled during thread switch.

Capture B: IAB/sidebar still starts during switch; CPU/memory not saturated

Captured locally at 2026-05-29T07:59:19-05:00.

Memory was not exhausted:

FreeGB  : 15.2
TotalGB : 31.7

Three-second CPU sample did not show system saturation; the Desktop app was alive but the UI briefly froze.

Switching into the affected thread produced:

07:59:06.218 | [browser-session-registry] IAB_LIFECYCLE rebound browser sidebar window ownerWebContentsId=1 previousOwnerWebContentsId=1 windowId=1
07:59:06.219 | [browser-session-registry] browser_use_iab_backend_startup_started backend=iab platform=win32 release=26.519.81530 routeKey=1:<thread-id>
07:59:06.223 | [browser-use-native-pipe-server] browser-use native pipe listening pipePath=\\.\pipe\codex-browser-use-...
07:59:06.223 | [browser-session-registry] browser_use_iab_backend_startup_ready backend=iab ...
07:59:07.035 | [BrowserUseThreadConfig] browser_use_runtime_paths_selected codexCliPath=...\codex.exe ...
07:59:07.642 | codex_core::shell_snapshot ... thread/resume ... Failed to create shell snapshot for powershell: Shell snapshot not supported yet for PowerShell

Workarounds tried

• Full clean Codex restart.
• Clearing Codex renderer caches and logs_2.sqlite/WAL/SHM.
• Disabling browser@openai-bundled temporarily.
• Setting BROWSER_USE_AVAILABLE_BACKENDS = "chrome" in the node REPL env scope and launching Codex with that environment variable for an isolation test.
• Restoring browser afterward because the freeze path still occurred and the Desktop app continued to start/rebind the IAB/sidebar route.

These did not resolve the underlying brief UI freeze. The browser-disable experiment also suggests the observed Desktop sidebar/IAB route is not controlled by the plugin/backend config that was toggled.

Related-looking issues

• #20867
• #21232
• #21948

Impact

This makes Codex Desktop unreliable for ordinary thread switching on Windows. The user can trigger visible "Not Responding" stalls simply by clicking between threads, including cases where no model turn is actively running.