Windows desktop app becomes unresponsive when switching tasks across Projects

Start by reproducing task switching across Projects in the Windows Codex desktop app while observing task/thread selection, conversation hydration, and renderer/main-process work. Use the supplied recordings and, if provided privately, the Windows Performance Recorder trace to identify the blocking path; done means the cause is isolated and the interface remains responsive while existing task content loads.

Summary

The Windows Codex desktop app intermittently becomes unresponsive when switching between tasks, including tasks in different Projects. While the task content is loading, the UI may stall: scrolling is choppy, the composer accepts text with visible delay, and the newly selected task content takes a noticeable time to render.

This is an interface responsiveness problem, not a slow model-response problem. It is reproducible while selecting an existing task before sending a new prompt.

Environment

• Product: OpenAI Codex desktop app for Windows
• Package: OpenAI.Codex
• App version: 26.715.2305.0
• Package full name: OpenAI.Codex_26.715.2305.0_x64__2p2nqsd0c76g0
• OS: Windows 11 x64

Steps to reproduce

1. Open the Codex desktop app with multiple existing tasks across two or more Projects.
2. Select a task, then switch to another task in a different Project.
3. Repeat switching between several existing tasks.
4. While the selected task is loading, scroll the toolbar or click into the composer and type.

Actual result

• Task content renders slowly after selection.
• The app can freeze briefly while a task loads.
• Scrolling and typing become visibly laggy during the freeze.
• The problem has recurred across sessions; restarting the app or machine is not a reliable remedy.

Expected result

Selecting an existing task should keep scrolling, typing, and the rest of the interface responsive, even if task history is still loading in the background.

Evidence collected locally

• Two screen recordings show the reproduction:
  • lag 1.mp4: 22.43 s, 720x1280, 30.005 fps, 673 frames.
  • lag 2.mp4: 36.297 s, 720x1280, 30.002 fps, 1089 frames.
• During a 40-second task-switch capture, the primary ChatGPT process accumulated approximately 27 CPU-seconds and a renderer-like ChatGPT process approximately 11 CPU-seconds. This points to desktop-app work during the UI stall but does not identify a specific code path.
• A Windows Performance Recorder trace captured 45 seconds, 1,275,316 events, zero lost events, and 86,592 CPU samples. The ETL is retained locally and can be provided through a private channel if useful.

The videos and ETL are intentionally not attached here because they may contain user/task or machine metadata.

Exclusions checked locally

• The recordings remain at approximately 30 fps, so this is not recording frame loss.
• Intel Smart Sound Technology OED status is OK; audio is unrelated to the interaction delay.
• Windows event logs did not show matching ChatGPT/Codex application crashes or display-driver warnings during the latest check.
• Roughly 7 GB of RAM was available during the latest process sample, so the machine was not under obvious memory exhaustion.

Request

Please investigate the Windows desktop app path for task/thread selection, conversation hydration, and renderer/main-process work. In particular, determine whether loading existing task history, diffs, or Project metadata can block the UI thread rather than being incremental/background work.

Similar reports

• #20214
• #11011
• #25390