Repository navigation
Windows Desktop freezes briefly when switching into browser-use-associated thread; IAB/sidebar starts during thread switch #25094
Description
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.exefile 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
- Codex is open on Windows.
- User switches/clicks into an existing thread whose Desktop logs show browser/sidebar lifecycle state during thread entry.
- Codex briefly freezes and Windows may show "Not Responding".
- 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-bundledtemporarily. - 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
- Windows 26.429 desktop becomes unresponsive with long threads, MCP auto-start duplicates, and non-Git workspace warnings #20867
- Codex App freezes / becomes Not Responding when opening image-heavy projects with many generated images #21232
- Large active session causes global freezes with no UI attribution #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.
Activity
rajnpatel commentedon May 29, 2026
Additional evidence from a longer hang on 2026-05-29 around 10:00 AM America/Chicago.
User reported Codex froze for about 5 minutes. A fresh local evidence capture immediately afterward produced a new Windows Error Reporting event:
The same capture still does not look like simple memory exhaustion:
Codex app state around the capture showed multiple thread/session states still marked as streaming, including threads without active runtimes:
Logs around the same window included:
I also checked nearby Windows Store update failures at 09:49; AppX logs show those were for Microsoft.YourPhone / OfficeHub / Photos, not Codex, so I do not think those explain the Codex hang.
Local capture filename:
codex-freeze-20260529-100104.md. It contains more raw process/log detail if a sanitized excerpt would help.rajnpatel commentedon May 29, 2026
Additional reproduction from a different thread on 2026-05-29 around 18:40 America/Chicago.
Trigger this time was simply clicking the thread named
Review asset pack chatto read a new message. No typing or explicit browser action was needed.Session index maps that thread to:
Windows logged another fresh Codex hang:
The immediate capture again did not show memory exhaustion:
App state again showed stale streaming/session bookkeeping with no inflight turn at first:
Relevant logs around the click/resume path:
This seems to further narrow the issue to ordinary thread switching / resume state reconciliation in Codex Desktop, with completed turns being restored as
markedStreaming=trueand browser/sidebar state rebounding during or shortly after the transition.rajnpatel commentedon May 31, 2026
Additional evidence after Codex Desktop updated to a newer build.
As of 2026-05-31, the installed Store package is now:
The problem is still occurring on the newer build, and it has escalated from brief hangs to repeated hangs plus at least one fatal app hang where Windows closed Codex.
Windows Error Reporting events seen on 2026-05-31 local time:
The archived WER report for the fatal hang contains:
There are also new Crashpad dump files under the new web profile path:
A fresh local diagnostic capture at
codex-freeze-20260531-094047.mdshowed this was not simple memory exhaustion:It also showed much worse stale thread/session state than earlier captures:
Recent logs still show repeated
codex-browser-useinitialization and IAB/browser route churn for several restored/resumed threads, plus repeatedelectron-samplerchild-process snapshot failures.One additional local-state issue appeared after the update: config had
chrome@openai-bundledenabled, but the cache pathC:\Users\<user>\.codex\plugins\cache\openai-bundled\chrome\0.1.7contained noplugin.json, producing repeated warnings:I disabled only that broken Chrome plugin entry locally as a narrow mitigation. I did not lower reasoning effort and did not disable the in-app browser plugin.