Codex Desktop becomes extremely sluggish when opening very large local thread on Windows

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

OpenAI.Codex app 26.527.3378.0; Codex CLI/Doctor 0.135.0-alpha.1

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?

Codex Desktop for Windows becomes extremely sluggish/freezing-like when opening or switching back to a very large local conversation thread. The same workflow through the Codex extension inside Antigravity is much smoother, so this appears specific to Codex Desktop's local transcript/history rendering path.

Affected local thread:

• Sanitized title: Cikan hatayi duzelt
• Thread id: 019e5fe0-5e81-7a02-abef-f2bde9c26a4a
• Rollout/history size: 242.5 MB
• 50,589 JSONL lines
• 29,169 response_item records
• 21,178 event_msg records
• 10,538 function_call records
• 112 input_image records
• 87 lines larger than 1 MB
• Max JSONL line: 3,631,856 characters

Observed when selecting/opening the thread:

• thread/resume took 7,760 ms, later 3,153 ms
• thread/goal/get took 8,606 ms, later 2,087 ms
• Windows still reports Codex processes as responding, but UI interaction becomes extremely slow
• Total Codex private memory was about 1.95 GB
• Main renderer-like Codex.exe process was about 695-825 MB
• app-server/renderer CPU stayed high
• System RAM was not exhausted

What steps can reproduce the bug?

Feedback ID: 019e77a2-d87b-7960-a86b-1a7462d09bcc

1. Use Codex Desktop on Windows.
2. Work in one local thread for many hours, with lots of tool output, screenshots/images, and long transcript history.
3. Let the local rollout/history become very large. In this case it reached 242.5 MB and 50,589 JSONL lines.
4. Switch away from the thread, then reopen/select it from the Codex Desktop sidebar.
5. Observe multi-second thread/resume and thread/goal/get work, high app-server/renderer CPU, and extremely sluggish UI interactions.

This is difficult to reproduce with a tiny sample because the failure appears tied to accumulated local history size and image/tool-output payloads.

What is the expected behavior?

Codex Desktop should remain responsive when selecting a long local thread. Long transcript/tool-output/image history should be virtualized or lazily rendered/hydrated, with large base64/image payloads kept off the renderer's critical path.

Users should not need to manually hand over to a new thread every few hours just to keep the Desktop UI usable.

Additional information

Tried locally:

• Set desktop conversationDetailMode=STEPS_PROSE and verified config with codex doctor. This reduces detail but does not solve slow opening of the large thread.
• Checked state/rollout inventory.
• Cleaned duplicate helper/MCP processes.
• Verified system RAM was not exhausted.

Possibly related open issues found before submitting: #21134, #24676, #20544, #21232, #24510, #23919. This report adds current Windows Desktop version, exact local rollout metrics, and the Antigravity Codex extension comparison.