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

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.