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

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

• #24676

Powered by Codex Action

I can confirm a second Windows Desktop repro with another large local thread.

Local read-only measurements from my affected thread:

• Platform: Windows, Codex CLI from session_meta: 0.142.5
• Thread title: sanitized as Coding
• Thread id: 019f1f87-b799-72f3-8995-c31754f7d8a8
• Rollout JSONL size: 123,931,333 bytes / 118.19 MiB
• JSONL lines: ~39,487
• Records: 24,718 response_item, 14,628 event_msg, 75 turn_context, 3 session_meta
• Response payloads include 7,456 function_call, 7,455 function_call_output, 4,377 message, 4,238 reasoning
• 23 lines are larger than 512 KiB
• 9 lines are larger than 1 MiB
• Max JSONL line: 1,261,771 chars / ~1.20 MiB

This is the largest active local thread on my machine. The next largest active session is only ~28.02 MiB, so this thread is ~4.2x larger than the next one.

The Desktop UI becomes very sluggish when working with / switching back to this thread. The file was also actively open/appended by Codex while being measured, so this looks like a live long-session path, not only an archived-history problem.

This supports the hypothesis that Desktop is doing too much transcript hydration/parsing/rendering on the critical path for large local rollout JSONL files. Lazy loading, virtualization, summary/index-first loading, and keeping large tool-output/reasoning/function-call payloads off the initial renderer path would likely help.

Adding a privacy-safe cross-report synthesis from the existing public tracker evidence:

• #18693 reports broader typing, scrolling, thread-list, and switching degradation around a few very large local histories across macOS, with additional Windows reports in its comments.
• #12709 describes progressive typing, scrolling, and rendering lag in longer macOS threads; its author later noted that MCP was not clearly the cause and that restarting or starting a fresh thread only temporarily helped.

This is qualitative corroboration only. The reports are heterogeneous and do not establish a shared root cause, prevalence, or a history-size threshold. I do not have a publishable local symptom record, measurements, or controlled reproduction to add. Rotating work into a fresh task is a workflow mitigation, not a diagnosis or a measured fix.

Adding a current native-Windows reproduction from Codex Desktop client 26.727.51351 with bundled app-server 0.146.0-alpha.9.2.

The affected active task has an approximately 12 MiB rollout containing about 4.9k items. After a clean Desktop restart:

• The backend began logging in the same second that its process started, so general backend startup was not delayed.
• Opening the affected task produced two thread/resume requests for the same task.
• The first rollout read began immediately.
• Plugin and skill initialization appeared about eight seconds later.
• Authentication and MCP initialization continued until roughly thirteen seconds after the task was opened.
• Transcript reconstruction completed at approximately the same thirteen-second point.
• Desktop then issued nine thread/turns/list requests clustered into roughly two seconds.
• Each thread/turns/list request reconstructed the complete approximately 4.9k-item rollout.
• Including the other reads in the opening sequence, the rollout was reconstructed eleven times. That represents approximately 133 MiB of logical source-history reprocessing, not a measurement of physical disk I/O.

The visible symptom is a long wait for task content and noticeable input lag in the Desktop UI.

As controls, all schedules were paused and all tasks were unpinned before restarting Desktop. The remaining task-opening delay persisted. This does not prove that schedules or pinned tasks never contribute to other startup work; it shows that they do not explain this reproduction.

What the trace establishes is that opening one task waits alongside initialization work and triggers repeated complete-history reconstruction. It does not by itself establish how much of the perceived latency comes from app-server processing versus renderer work.

This appears related to #33786, but the observed request pattern here is a burst during task opening rather than proven continuous background polling. The much smaller approximately 12 MiB history also suggests that the behavior is not confined to exceptionally large multi-hundred-megabyte rollouts.

A small reproducibility aid for Windows reports: I published a read-only PowerShell checker that locates one local rollout by task UUID and reports its path, size in MiB, modification time, automatic-compaction count, and the latest input/window ratio. It does not modify the session or print conversation bodies.

Tool and usage notes:
https://github.com/RongNianXin/codex-workflows/tree/30f217f/实用小工具/查看当前任务本地对话的文件大小

Important limitation: file size, compaction count, and context ratio are diagnostic signals only. They do not by themselves establish that transcript size is the cause of renderer lag, repeated hydration, network delay, or model behavior. For an upstream report, I would still include the Codex/Desktop version, OS, a sanitized timing trace, and a comparison with a smaller task.

Disclosure: I maintain the linked community repository; it is not affiliated with OpenAI. I am sharing it here as a privacy-conscious measurement helper, not as a confirmed fix or as evidence for a universal size threshold.