›_ Codex Issues
Codex Issues / #23235

Codex Desktop opening old conversations is blocked by slow resume hydration despite fast thread read

Open 💬 3 comments Opened May 18, 2026 by aveschien
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

Opening/resuming older Codex Desktop conversations can stay in the loading/resuming state for several seconds, even though the raw local thread read is effectively immediate.

Environment

  • Codex Desktop for Windows
  • AppX package version: 26.513.4821.0
  • Observed after updating Codex Desktop
  • Details below are sanitized from local desktop diagnostics

What I observed

When opening an older conversation after a cold start / app update, the UI remained blocked while the app performed resume/hydration work.

Sanitized timings from a local desktop log:

  • thread/read: ~7 ms
  • thread/resume: ~4,895 ms
  • thread/goal/get: ~4,897 ms
  • mcpServerStatus/list: ~13,761 ms
  • thread/list: up to ~17,630 ms

This suggests raw thread reading is not the bottleneck. The user-visible delay appears to be tied to resume/goal hydration and startup-side status/list work.

Expected behavior

The conversation should render quickly once local thread data is available. Resume, goal, MCP status, and thread-list hydration could continue in the background where possible.

Actual behavior

Opening older conversations can stay visually blocked until resume and related calls complete.

Additional notes

In the desktop bundle, I found code paths around maybe-resume-conversation, thread/resume, thread/goal/get, thread/list, and a gated useTailHydration() path. In the observed logs, I did not see the lightweight tail-hydration path being used, so this may be falling back to heavier resume behavior.

No screenshots or raw logs are attached because they may contain private conversation metadata.

View original on GitHub ↗

3 Comments

github-actions[bot] contributor · 3 months ago

Potential duplicates detected. Please review them and close your issue if it is a duplicate.

  • #22912
  • #22981
  • #22411
  • #22053
  • #22969

Powered by Codex Action

nasadunadu · 1 month ago

I can reproduce the same issue on macOS, and the local diagnostics strongly support the conclusion that raw thread reading is not the bottleneck.

Environment

  • macOS (Apple Silicon)
  • Codex Desktop: 26.707.41301 (build 5103)
  • Renderer: 150.0.7871.115
  • Bundled Codex CLI / app-server: 0.144.0-alpha.4
  • Observed after the Desktop update; reinstalling the current official build did not change the behavior

Sanitized timings

Before local mitigation:

  • thread/list: approximately 115-276 ms
  • thread/read: approximately 2-6 ms
  • thread/resume: approximately 6.6-14.1 s
  • mcpServerStatus/list: approximately 10.8-15.6 s
  • thread/turns/list: approximately 420-490 ms per page for a larger thread

For comparison, older local logs from renderer build 149.0.7827.54 showed:

  • ordinary thread/resume: approximately 1.8 s
  • thread/turns/list: approximately 44-54 ms per page

Local mitigation attempted

I tested all of the following while preserving the same threads:

  • cold-archived multi-gigabyte old rollout history
  • compacted the local log database
  • disabled or removed nonessential plugins and MCP registrations
  • switched the conversation detail mode from command-heavy rendering to prose
  • reset the complete Electron/Chromium UI state directory (about 234 MB before reset)
  • reinstalled the current official Desktop build

These mitigations improved thread/resume to roughly 1.6-2.8 s for ordinary threads, but the UI still displays a blank/loading surface until resume completes. The UI-state reset also reduced app-server RSS substantially, confirming that local state amplified the issue but was not the root cause.

A fresh UI-state directory still logs repeated:

ResizeObserver loop completed with undelivered notifications

Expected behavior

The newest visible turns should render immediately after the very fast thread/read response. Runtime resume, MCP/plugin status, goal hydration, and older-turn pagination should continue in the background and should not block the initial conversation paint.

This appears to be cross-platform and consistent with the Windows evidence already reported here. I have intentionally omitted raw logs, local paths, thread IDs, and private conversation metadata.

junxin367 · 1 month ago

The issue has still not been fixed as of today.