›_ Codex Issues
Codex Issues / #25094

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

Open 💬 3 comments Opened May 29, 2026 by rajnpatel

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.

View original on GitHub ↗

3 Comments

rajnpatel · 3 months ago

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:

TimeCreated: 2026-05-29 10:00:30 AM
Provider: Windows Error Reporting
Event Name: AppHangTransient
P1: Codex.exe
P2: 3178.0.0.0
Report Id: 73a8585f-fb3e-4e48-9ea8-896c4f185990

The same capture still does not look like simple memory exhaustion:

FreeGB: 14.7
TotalGB: 31.7

Codex app state around the capture showed multiple thread/session states still marked as streaming, including threads without active runtimes:

thread_count_active: 3 -> 4
thread_count_streaming_owner: 3 -> 4
thread_count_streaming_with_active_runtime: 1 -> 2
thread_count_streaming_without_active_runtime: 2 -> 3
inflight_turn_count: 1 -> 2
renderer_process_working_set_kb: ~1.1 GB
host_descendant_process_rss_kb_total: ~3.1 GB

Logs around the same window included:

10:00:30 fs/watch requests failed with: Invalid request: AbsolutePathBuf deserialized without a base path
10:00:32 electron-sampler failed to collect child process snapshot
10:00:33 IAB_LIFECYCLE rebound browser sidebar window
10:00:35 maybe_resume_success ... latestTurnStatus=completed markedStreaming=true
10:00:51 turn/start followed by IAB_LIFECYCLE captured turn route
10:00:58 IAB_LIFECYCLE rebound browser sidebar window
10:01:05 IAB_LIFECYCLE rebound browser sidebar window

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 · 3 months ago

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 chat to read a new message. No typing or explicit browser action was needed.

Session index maps that thread to:

conversationId: 019e7521-41dc-7731-a9d5-ab27f024bb8b
thread_name: Review asset pack chat

Windows logged another fresh Codex hang:

TimeCreated: 2026-05-29 18:40:48
Provider: Windows Error Reporting
Event Name: AppHangTransient
P1: Codex.exe
P2: 3178.0.0.0
Report Id: 6b340e21-f778-408c-b083-57c130226d79

The immediate capture again did not show memory exhaustion:

FreeGB: 14.4
TotalGB: 31.7

App state again showed stale streaming/session bookkeeping with no inflight turn at first:

thread_count_loaded_recent: 44
thread_count_active: 2 -> 4
thread_count_streaming_owner: 2 -> 4
thread_count_streaming_with_active_runtime: 0 -> 1
thread_count_streaming_without_active_runtime: 2 -> 4 -> 3
inflight_turn_count: 0 -> 1

Relevant logs around the click/resume path:

18:40:29 thread/read conversationId=019e7521-41dc-7731-a9d5-ab27f024bb8b durationMs=5
18:40:32 thread/resume conversationId=019e7521-41dc-7731-a9d5-ab27f024bb8b durationMs=1081
18:40:33 maybe_resume_success conversationId=019e7521-41dc-7731-a9d5-ab27f024bb8b latestTurnStatus=completed markedStreaming=true turnCount=22
18:40:49 IAB_LIFECYCLE rebound browser sidebar window
18:40:50 another thread resume also reports latestTurnStatus=completed markedStreaming=true
18:40:51 electron-sampler failed to collect child process snapshot
18:40:52 IAB_LIFECYCLE rebound browser sidebar window

This seems to further narrow the issue to ordinary thread switching / resume state reconciliation in Codex Desktop, with completed turns being restored as markedStreaming=true and browser/sidebar state rebounding during or shortly after the transition.

rajnpatel · 2 months ago

Additional evidence after Codex Desktop updated to a newer build.

As of 2026-05-31, the installed Store package is now:

OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0
Codex Desktop client version in logs: 26.527.31326
WER app version: 148.0.7778.179
Windows: 11 Home 25H2 / 10.0.26200.x

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:

07:52:45 AppHangTransient Report Id: f209e655-6bc0-47d2-8991-6e75c07ee9f9
08:56:13 AppHangTransient Report Id: 60bfec12-0dfc-471d-a241-b07b1061ed79
08:59:21 MoAppHang        Report Id: 76061960-ac88-4d2c-81b5-7bb0d6167db8
08:59:21 Application Hang: The program Codex.exe version 148.0.7778.179 stopped interacting with Windows and was closed.
09:00:32 AppHangTransient Report Id: 5d1dc9db-4d49-4301-9760-bef1902fae96
09:03:14 AppHangTransient Report Id: 933c85ee-9ca8-4d9d-8fdd-6261836456d6
09:05:27 AppHangTransient Report Id: 0ab60d30-2035-42ad-9811-faf318b43027
09:39:11 AppHangTransient Report Id: ff4cdc6c-2056-4df8-a383-916b10137c7e

The archived WER report for the fatal hang contains:

EventType=MoAppHang
TargetAppId=U:OpenAI.Codex_26.527.3686.0_x64__2p2nqsd0c76g0!App
TargetAppVer=26.527.3686.0_x64_!2026//05//18:23:20:44!0!Codex.exe
IsFatal=1
UI[3]=Codex is not responding
Sig[4].Name=Hang Signature
Sig[4].Value=acf7
Sig[5].Name=Hang Type
Sig[5].Value=134217728
IntegratorReportIdentifier=76061960-ac88-4d2c-81b5-7bb0d6167db8

There are also new Crashpad dump files under the new web profile path:

C:\Users\<user>\AppData\Roaming\Codex\web\Codex\Crashpad\reports\f9ea7141-d055-48b2-81e2-368be8c961b9.dmp
LastWriteTime: 2026-05-31 09:33:35
Size: ~40.8 MB
SHA256: 837420E4EA84E39BA6B7B8E88C953390ED753CCA53B3DBE6DC8907F5BBCC3F6F

C:\Users\<user>\AppData\Roaming\Codex\web\Codex\Crashpad\reports\13ada242-2d27-4d03-b928-10c8a2af078b.dmp
LastWriteTime: 2026-05-31 09:37:38
Size: ~40.7 MB
SHA256: CCBA219B105CE5CD56017C77FED99EEE42F02831FC303D6F084E7127BEAC4A01

A fresh local diagnostic capture at codex-freeze-20260531-094047.md showed this was not simple memory exhaustion:

FreeGB: 13.7
TotalGB: 31.7

It also showed much worse stale thread/session state than earlier captures:

thread_count_loaded_recent: 49
thread_count_active: 8
thread_count_streaming_owner: 4
thread_count_streaming_with_active_runtime: 1 -> 0
thread_count_streaming_without_active_runtime: 7 -> 8
inflight_turn_count: 1 -> 0

Recent logs still show repeated codex-browser-use initialization and IAB/browser route churn for several restored/resumed threads, plus repeated electron-sampler child-process snapshot failures.

One additional local-state issue appeared after the update: config had chrome@openai-bundled enabled, but the cache path C:\Users\<user>\.codex\plugins\cache\openai-bundled\chrome\0.1.7 contained no plugin.json, producing repeated warnings:

failed to load plugin: missing or invalid plugin.json plugin="chrome@openai-bundled" path=...\chrome\0.1.7

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.