Skip to content

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

Open

Description

@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

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

  1. rajnpatel commented on May 29, 2026

    @rajnpatel
    Author

    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.

  2. rajnpatel commented on May 29, 2026

    @rajnpatel
    Author

    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.

  3. rajnpatel commented on May 31, 2026

    @rajnpatel
    Author

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugSomething isn't working

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions