codex - 💡(How to fix) Fix 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.