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

Activity

1. riyadist

   added

   appIssues related to the Codex desktop appIssues related to the Codex desktop app

   on May 31, 2026
2. github-actions

   added

   bugSomething isn't workingSomething isn't working

   windows-osIssues related to Codex on Windows systemsIssues related to Codex on Windows systems

   performance

   sessionIssues involving session (thread) management, resuming, forking, naming, archivingIssues involving session (thread) management, resuming, forking, naming, archiving

   on May 31, 2026
3. github-actions commented on May 31, 2026

   

   github-actionsbot

   on May 31, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • Codex Desktop hangs when opening an image-heavy session rollout (~183 MB, huge inline image_url records), and the thread becomes hard to recover from the sidebar #24676

   Powered by Codex Action
4. pomazanbohdan commented on Jul 3, 2026

   

   pomazanbohdan

   on Jul 3, 2026

   More actions

   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.
5. Eliagiac commented on Jul 15, 2026

   

   Eliagiac

   on Jul 15, 2026 – with ChatGPT Codex Connector

   More actions

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

   • Desktop performance collapses in profiles with a few very large local conversation histories (typing, scrolling, thread list, random exits) #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.
   • Codex Desktop on macOS becomes progressively slow and causes system-wide lag during long MCP-heavy sessions #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.

   👍React with 👍1Reacted by Pomazan Bohdan
6. meza commented on Aug 1, 2026

   

   meza

   on Aug 1, 2026

   Last edited by meza

   More actions

   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.
7. RongNianXin commented on Aug 20, 2026

   

   RongNianXin

   on Aug 20, 2026

   More actions

   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.
8. jahidrfc commented on Aug 31, 2026

   

   jahidrfc

   on Aug 31, 2026

   More actions

   Additional sanitized large-history measurements from Windows:

   Completed RPC latency in a stable log sample:

   Method	n	p50	p95	p99	max
   thread/read	339	56 ms	5.54 s	86.02 s	86.72 s
   thread/list	1,389	110 ms	9.96 s	86.24 s	181.08 s

   In the current affected run, thread/list reached 257.65 seconds. Queue waits were generally tiny compared with total elapsed time, suggesting the long tail was mainly service time after dispatch rather than time waiting in the client queue.

   Only 3–7 recent tasks were represented in sampled loaded-state snapshots, but the corresponding hydration telemetry reported 19,243–28,055 items and 173–358 turns held. One turn reached 2,503 items. I did not observe cursor, limit, page, offset, hasMore, or nextCursor fields in the thread/read telemetry; logging may omit request parameters, so this is not proof that pagination is absent.

   One anonymized XL archived-rollout sample contained:

   • 297.121 MiB
   • 58,617 records
   • 469 turn_context records
   • 514 user_message records
   • 81.4% of event records were token_count or reasoning events

   Aggregate archived corpus at measurement time:

   • 4,611 JSONL files
   • approximately 49.2 GiB total
   • 100 files over 100 MiB
   • 44 over 250 MiB
   • 26 over 500 MiB
   • one over 1 GiB

   These observations do not establish formal O(n) complexity, but they support the narrower claim that time-to-interactive appears history-dependent and that bounded per-thread hydration is not evident in available telemetry. A useful acceptance target would be indexed metadata plus a fixed byte-bounded recent page on the critical path, with older turns and event-heavy detail virtualized or loaded in the background. Startup and first interaction should not synchronously replay full retained history.

   This appears closely related to #16158 and #21211.

   No raw logs, task IDs, filesystem paths, prompts, record contents, account data, or screenshots are included.
9. RongNianXin commented on Aug 31, 2026

   

   RongNianXin

   on Aug 31, 2026 – with ChatGPT Codex Connector

   More actions

   Thanks for the careful, privacy-safe measurements. The queue-wait versus service-time split is especially useful, and I agree that the available telemetry does not prove missing pagination or formal O(n) behavior.

   These data make the history-dependent critical-path hypothesis more concrete than a file-size threshold alone. For future comparisons, Desktop/app-server version, rollout size and record mix, cold versus warm open, and thread/list and thread/read percentiles would make a useful minimal measurement set.

   I’ll keep the size, compaction, and context figures from the helper I shared above labeled as screening signals rather than causal evidence.