[Windows][Desktop 26.707.9981.0] Post-merge thread switching and prompt submission freeze with thread/resume latency and ResizeObserver errors #33524

What version of the Codex App are you using (From “About Codex” dialog)?

26.707.9981.0

What subscription do you have?

ChatGPT Pro

What platform is your computer?

Microsoft Windows NT 10.0.26200.0 x64

What issue are you seeing?

After the standalone Codex experience migrated to the unified ChatGPT/Codex desktop app, opening existing local conversations and submitting prompts began causing severe local UI stalls.

The symptoms are:

• Clicking a previously unopened history conversation can blank or freeze the entire app window for several seconds to over a minute.
• During the stall, the conversation, composer, mouse interaction, and the rest of the app UI stop responding.
• Returning to an already warmed conversation can be faster, but the behavior is not reliably bounded.
• Prompt submission now triggers a similar stall before the message is visibly accepted.
• The experience feels like a local computer/UI freeze rather than network latency.

The regression became visible immediately around the ChatGPT/Codex desktop merge. The first precise slow-resume and renderer-error timestamps observed locally were:

• First thread/resume over 5 seconds: 2026-07-10 11:40:03 Beijing Time (UTC+8) / 2026-07-09 20:40:03 US Pacific Daylight Time (PDT, UTC-7) / 2026-07-10 03:40:03 UTC. Duration: 10.121 seconds.
• First ResizeObserver loop completed with undelivered notifications. error: 2026-07-10 11:48:05 Beijing Time / 2026-07-09 20:48:05 PDT / 2026-07-10 03:48:05 UTC.

Before/after measurements

Calendar-day aggregation below uses Beijing Time. For clarity, a Beijing calendar day spans 09:00 on the previous PDT date through 08:59:59 on the same-numbered PDT date.

Additional observed maxima:

• thread/start: 37.530 seconds
• mcpServerStatus/list: 97.056 seconds
• plugin/list: 30.087 seconds
• skills/list: 4.687 seconds
• Ordinary thread/list calls were usually approximately 1–24 ms, so the conversation-list RPC/network path itself does not explain the foreground freeze.

The logs also repeatedly show Browser/sidebar lifecycle warnings, unknown-conversation events, and renderer-side ResizeObserver loops during the affected period.

Local-state observations

These are included as possible amplifiers, not as confirmed root causes:

• 158 local session files, approximately 601.68 MiB total.
• Session-file size does not explain the stalls: across 221 mapped resume events, the correlation between rollout size and thread/resume duration was approximately -0.058. Small sessions under 0.5 MiB also produced 50–60+ second resumes.
• 10 enabled plugins and 3 configured MCP servers.
• Plugin files total approximately 446.91 MiB.
• Active %USERPROFILE%\.codex\logs_2.sqlite: 254.17 MiB, 96,923 rows, SQLite quick_check=ok.
• The log DB had 65,068 pages with 27,858 freelist pages, approximately 42.8% reusable/free pages. This indicates substantial retained free space/fragmentation even though the database is structurally valid.
• The unified ChatGPT/Codex process family used approximately 1.4 GiB working set during inspection.

No session history, database, plugin, MCP, or UI cache was reset before collecting these measurements. No destructive A/B cleanup was performed.

This appears to be a foreground orchestration/rendering regression in the unified desktop app, potentially amplified by persisted state. Opening a conversation appears to combine expensive resume/history work with plugin, skill, app, MCP, browser-sidebar, and renderer updates instead of keeping the UI responsive and progressively hydrating state.

What steps can reproduce the bug?

1. Use ChatGPT/Codex Desktop 26.707.9981.0 on Windows x64 with existing local conversations.
2. Fully launch the app and wait for the initial window to become idle.
3. Click an existing history conversation that has not yet been opened during the current app run.
4. Observe that the window becomes blank, frozen, or non-interactive while thread/resume completes.
5. Repeat with several different existing conversations.
6. Open a conversation and submit a new prompt.
7. Observe that prompt submission can also freeze the app before the message is visibly accepted.
8. Inspect Desktop logs and observe multi-second thread/resume, thread/start, plugin/skills/MCP status calls, plus repeated ResizeObserver loop completed with undelivered notifications. errors.

This reproduces with both small and large conversations. No model generation is required to reproduce the history-navigation stall.

What is the expected behavior?

• Opening an existing conversation should show lightweight metadata and the recent visible turns immediately.
• Older history should hydrate progressively without blocking the renderer or composer.
• The composer should remain interactive while plugin, skill, app, MCP, Git, browser-sidebar, or diagnostic-log work continues in the background.
• Read-only navigation should not eagerly initialize or retain expensive per-thread runtimes.
• Slow local state, fragmented diagnostic storage, or one slow integration should not freeze the entire Electron window.
• Prompt submission should be acknowledged immediately and must not wait on unrelated reconciliation work.

Additional information

Potentially related reports:

• Codex Desktop becomes unresponsive when opening previous conversations; thread history loading appears too eager #29590 — opening previous conversations becomes unresponsive; history loading appears too eager
• Codex Desktop becomes unusable on long active threads due to app-server/renderer memory and TRACE log churn #21134 — app-server/renderer memory and TRACE log churn; Windows reports also identify oversized or fragmented logs_2.sqlite as an amplifier
• Windows/WSL2: Desktop retains one eager MCP stack per opened chat and replays history during navigation #32154 — eager per-thread MCP stacks and persisted-history replay during navigation
• Regression: Desktop 26.707 replays legacy thread history and emits 1,282 parse errors per page, freezing the Windows UI #32198 — Desktop 26.707 repeatedly replays legacy history and freezes the Windows UI
• Codex Windows app freezes for several seconds when opening any history conversation #33230 — Windows freezes for several seconds when opening history conversations
• [Windows App] skills/list blocks thread switching for 14–22s across 29 workspaces #33236 — skills/list blocks thread switching for 14–22 seconds
• ChatGPT Desktop: openaiDeveloperDocs makes thread/resume take 36 seconds #32654 — MCP configuration makes thread/resume take 36 seconds
• 26.707.72221 - App freezes immediate when accessing current threads. #33169 — Desktop 26.707 freezes when accessing current threads
• Windows Desktop UI freezes after typing a prompt (Application Hang: Top level window is idle / Quiesce) #31676 — Windows UI freezes after typing/submitting a prompt

This report is intentionally separate because it provides a precise pre/post-merge local timeline, timezone-normalized onset timestamps, daily resume-latency measurements, renderer-error counts, session-size correlation, and diagnostic-DB page statistics from the current 26.707.9981.0 Windows build.

Raw logs and rollout files are not attached because they can contain private prompts, local paths, commands, and credentials. Sanitized excerpts can be provided if maintainers identify the preferred fields and collection procedure.