Windows desktop: severe UI lag with multi-GB image-heavy conversations; recent history appears missing after restart

Summary

Codex Desktop on Windows becomes severely unresponsive while continuing long, image-heavy development conversations. Typing and switching windows noticeably lag. The user reports that responsiveness returns when conversations are not running or after exiting Codex.

Separately, after quitting and relaunching, some affected conversations display older progress instead of recent messages, although recent records remain in the local rollout JSONL. Please investigate both performance and conversation-history restoration; their common cause is not yet established.

Environment

• Windows desktop, x64
• Observed installed package: OpenAI.Codex_26.903.9818.0_x64
• Observed September 11, 2026 (UTC+08:00)
• Long-running local development tasks using browser screenshots and image inspection

Reproduction (user-observed)

1. Launch Codex. Initially it can be responsive.
2. Open/continue an existing long, image-heavy development conversation.
3. Typing and window switching become noticeably sluggish.
4. Stop task activity or exit Codex: responsiveness returns.
5. Quit and relaunch, then reopen an affected conversation: some recent progress is no longer visible and older content appears.

Expected: responsive UI during task execution and restoration of the latest persisted messages.
Actual: substantial interactive lag and apparently stale/incomplete restored history.

Read-only local findings

Two affected rollout files:

For A the largest record was 58,649,358 characters. Image metrics count whole records, not decoded image bytes or unique images.

A codex.exe process was observed with working set approximately 3,694–3,815 MiB during the earlier investigation. This is a snapshot, not proof of a memory leak.

For B:

• The local rollout contains assistant messages timestamped 2026-09-10T16:23:31.270Z and 2026-09-10T16:31:12.297Z (September 11 at 00:23 and 00:31 local).
• The last observed record is a turn_aborted event at 2026-09-11T00:44:07.925Z (08:44 local).
• These establish that at least some recent history was persisted.
• A read_thread request for the latest turn returned older progress and exactly 100 items. The interface has output limits, so this result is only supporting context, not independent proof of data loss or an indexing defect.
• User supplied a screenshot showing older restored content.

Impact and request

This disrupts ongoing development and makes recent work appear lost. Please triage large-rollout loading/stream updates and post-restart history restoration, and provide a fix or a supported recovery/workaround that preserves history.

Limits / privacy

No profiler trace or controlled fresh-versus-large-thread comparison has been captured. No confirmed memory leak, corruption, or permanent data loss is claimed. The two symptoms may have separate causes.
Raw conversations, screenshots containing project details, local user paths, and private thread identifiers are intentionally omitted from this public report. No session files were modified during investigation.

Start by reproducing with the two large local rollout JSONL files and compare UI responsiveness during image-heavy conversations with post-restart history restoration. Investigate large-rollout loading and stream updates alongside the read_thread result; done means the UI remains responsive and the latest persisted messages are restored after relaunch.