Windows Codex Desktop 26.715.2305.0 hangs while rendering ~200 KB tool output #33822

Activity

1. github-actions

   added

   bugSomething isn't workingSomething isn't working

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

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

   tool-callsIssues related to tool callingIssues related to tool calling

   performance

   on Jul 17, 2026
2. github-actions commented on Jul 17, 2026

   

   github-actionsBot

   on Jul 17, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • ChatGPT desktop app freezes when switching to a large image-heavy thread (ResizeObserver loop) #33782
   • Referenced chats (@-mention) injects entire prior conversation as a single message — permanent renderer freeze on every launch + unrecoverable compact deadlock #33008

   Powered by Codex Action
3. tonivix commented on Aug 15, 2026

   

   tonivix

   on Aug 15, 2026 – with ChatGPT Codex Connector

   More actions

   Additional Windows reproduction on a newer build:

   • Codex Desktop package: OpenAI.Codex_26.810.4967.0_x64
   • Platform: Windows x64
   • Trigger context: a very long existing task containing many image previews and large/truncated tool outputs. The whole desktop became sluggish, including mouse-pointer movement.
   • A file watcher initially looked suspicious, but I terminated its entire verified process tree; the lag remained.
   • RAM and disk were not constrained (about 49 GB physical RAM still available; disk queue was 0).
   • A direct 3-second process sample showed:
     • main ChatGPT.exe: about 141.7% CPU, about 650 MB working set
     • renderer ChatGPT.exe: about 75.0% CPU, about 913 MB working set
     • bundled codex.exe and codex-code-mode-host.exe: about 0% CPU
   • Combined main+renderer load was about 217% CPU while the backend was idle.
   • Closing another Electron application reduced symptoms, but fully exiting Codex produced immediate system-wide relief, including normal mouse movement.
   • Restarting/reopening Codex restored responsiveness for now.

   This looks consistent with a desktop main/renderer rendering or hydration loop in long, image-heavy, tool-heavy tasks, rather than model/backend work, the file watcher, disk, or memory pressure. Sanitized process details are available if useful.
4. CyberChun0329 commented on Oct 8, 2026

   

   CyberChun0329

   on Oct 8, 2026 – with ChatGPT Codex Connector

   More actions

   Additional Windows reproduction and reversible display-layer mitigation, observed on 2026-10-08.

   Environment: Windows x64, Microsoft Store package OpenAI.Codex 26.1002.7124.0.

   Opening an existing long conversation repeatedly froze the desktop UI. The same conversation remained able to receive instructions from other chats and continue its background work.

   Measured observations:

   • The live rollout was about 70.3 MB, with about 20,500 valid JSONL records and no malformed JSON in the captured snapshot.
   • The derived display history contained about 7,000 items. Individual historical command outputs reached 1,048,577 characters.
   • Native history read/resume and item-page requests returned in single-digit milliseconds in the inspected loading sequences.
   • The affected Electron renderer continuously consumed approximately one CPU core. Its private memory reached about 778 MiB.
   • Terminating only that renderer caused the app to reload it automatically. Reopening the same conversation reproduced sustained CPU saturation; the app main process and native app-server were preserved.

   A local, reversible experiment changed only the derived display index:

   1. Back up the exact original display rows.
   2. Shorten 60 completed command/function-output display fields that exceeded 20,000 characters, retaining a marked head/tail excerpt.
   3. Preserve the raw rollout, item IDs, all other item fields, turn records and projection cursor.
   4. Reload only the affected renderer and reopen the same conversation.

   The affected output fields fell from 6,263,068 to 1,200,000 displayed characters. After reopening, the main renderer accumulated 0.90625 CPU seconds over a 56.26-second observation window (about 1.61% of one core), rather than continuously saturating a core. The user subsequently confirmed that the conversation was working again. The same active backend turn continued, the native app-server stayed alive, and SQLite quick_check and all 60 repaired-row hash checks passed.

   This is an intervention result supporting historical-output display processing as a trigger. It does not isolate the offending item, JavaScript stack, or exact frontend defect. No ResizeObserver loop, OOM, GPU failure, or deadlock was established in this incident.

   This internal-index modification was a backed-up recovery experiment, not a supported user-facing setting or a recommended general repair procedure. The official app binary was not modified. Rebuilding the projection or accumulating new oversized historical outputs may reintroduce the problem.

   Please consider bounding historical tool-output processing before rendering, with a supported way to keep complete transcripts while displaying bounded excerpts. Inspection of this installed build found a 20,000-character bound for live command-output deltas, while hydrated historical command output was passed through without the same bound.

   Privacy: this comment contains only versions, aggregate counts, timings and process metrics. It includes no conversation text, local usernames/paths, project contents, thread/account identifiers, credentials, raw logs or display-index backups.