ChatGPT desktop 26.928: opening one long local chat repeatedly pegs renderer CPU and freezes the UI #50063

Environment

• macOS 15.5; ChatGPT desktop 26.928.31416 (build 12553), bundled Codex 0.159.2.
• The configured updater reports up_to_date.
• One affected local conversation has ~25,300 displayed items, ~367 turns, and a ~1.51 GB rollout. Other conversations open normally.

Reproduction and observed behavior

1. Open the affected long conversation in the macOS desktop app.
2. Scroll toward the newest messages. The view sometimes jumps weeks backward while older history loads.
3. The renderer becomes non-interactive and holds roughly one CPU core; the native main process and Codex backend remain mostly idle, and remote task execution continues.

This was reproduced repeatedly. During one minute after opening the affected conversation, the desktop log recorded 905 successful thread/items/list responses for that exact conversation and 167 aggregate thread_history_page spans. In another run it recorded 1,009 thread/items/list responses. A native renderer sample put the hot main thread in V8/JIT, but did not identify the JavaScript function. The UI became difficult to navigate away from; replacing only the stalled renderer and opening a short conversation temporarily returned it to normal CPU.

A controlled comparison held a short conversation open for 20 minutes without sustained high CPU. A different large conversation also did not trigger the same immediate loop. Opening the affected conversation in that same renderer produced sustained ~100% CPU within 60 seconds. Changing the chat model did not resolve it.

Data integrity and recovery attempts

Read-only SQLite quick_check passed. The history projection byte offset exactly matched the rollout file length; ordinals were monotonic, projected item JSON was valid, and displayed items matched completed journal events by ordinal and ID. There is no evidence that the local projection is stale or corrupt. No session, database, app bundle, or profile state was edited or deleted. Restarting the renderer or app gives only temporary relief.

Expected behavior / request

Long conversations should load progressively without repeatedly traversing the full history or freezing the desktop UI. Is there a supported way to cap historical UI hydration or capture a symbolized renderer JavaScript CPU profile on this build? Is a desktop fix planned?

Related but not proven identical: #18693 (large-history performance), #25163 (one large conversation freezes after an update), #37291 (wrong reopen scroll position), #17418 (erratic long-thread scrolling).

This report intentionally omits the conversation title and ID, transcript, raw logs, file paths, account information, and credentials. A longer sanitized timeline is available if maintainers request it.