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

Open 💬 2 comments Opened Jul 17, 2026 by eisenferik
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

26.715.2305.0 (Microsoft Store package)

What subscription do you have?

ChatGPT subscription (exact tier omitted)

What platform is your computer?

Windows 11 x64

GPU: NVIDIA GeForce RTX 4070

What issue are you seeing?

Codex Desktop repeatedly becomes unresponsive while rendering a large/streamed tool result. The failure reproduced across two threads and persists after restarting the app, rebooting Windows, and running Windows app repair.

A controlled reproduction generated approximately 200 KB / 800 lines of bounded text output in an active Codex thread. The UI froze at the same time, and Windows recorded an AppHangTransient / MoAppHang event.

During the reproduction:

  • Electron main-process private memory increased from approximately 214 MB to 1,025 MB within about 5 seconds.
  • Renderer memory increased from approximately 286 MB to 408 MB.
  • Multiple Codex processes showed high CPU utilization.
  • Codex logs emitted repeating ResizeObserver errors at roughly 10 ms intervals for the focused renderer.
  • Windows wait-chain inspection showed no blocked wait chain, which argues against a conventional lock/deadlock.
  • No system-wide memory, disk, GPU-device, or Git performance problem was present.
  • Codex CLI remains usable for the same work; the failure is localized to the desktop UI/rendering path.

This appears to be a renderer/layout feedback loop or unbounded UI hydration/rendering path triggered by sufficiently large tool output, rather than model latency or a backend request hang.

What steps can reproduce the bug?

  1. Launch Codex Desktop 26.715.2305.0 on Windows.
  2. Open an active thread.
  3. Run a local command/tool that returns approximately 200 KB of bounded text (about 800 long lines) as one result.
  4. Keep the Codex window focused while the result is displayed/streamed.
  5. Observe severe CPU and memory growth followed by the window becoming “Not Responding”.
  6. Check Windows Event Viewer / WER and observe an AppHangTransient / MoAppHang entry for the app.

The problem was also seen during ordinary tool-heavy work in two separate threads before the controlled reproduction.

What is the expected behavior?

Large tool results should be truncated, virtualized, collapsed, or rendered incrementally without blocking the Electron main/renderer process. The app should remain responsive and should not allocate around 800 MB of additional private memory within seconds.

Additional information

Observed controlled-reproduction timestamp: 2026-07-17 21:23:54 JST.

Sanitized process-monitor JSONL and targeted desktop-log excerpts are available if maintainers want them. Full logs are not attached because they may contain local paths or session metadata.

Possibly related, but not identical:

  • #22091 — tool-output retention/context growth can freeze old desktop sessions
  • #33782 — large image-heavy thread rendering and ResizeObserver loop
  • #16374 — intermittent Windows desktop UI freezes

View original on GitHub ↗

2 Comments

github-actions[bot] contributor · 1 month ago

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

  • #33782
  • #33008

Powered by Codex Action

tonivix · 13 days ago

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.