codex - 💡(How to fix) Fix Codex Desktop: opening a large thread causes sustained 100%+ CPU until app restart

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…

In Codex Desktop, opening a large existing conversation/thread can cause the Codex main process to stay at 100%+ CPU. Switching away to another conversation does not recover CPU usage; only fully restarting Codex clears it.

Root Cause

Large long-running agent threads with many tool calls become effectively unsafe to open in Codex Desktop, because one open can make the whole app sluggish until restart.

RAW_BUFFERClick to expand / collapse

Summary

In Codex Desktop, opening a large existing conversation/thread can cause the Codex main process to stay at 100%+ CPU. Switching away to another conversation does not recover CPU usage; only fully restarting Codex clears it.

Version

  • Codex Desktop version: 26.527.31326 (3390)
  • Platform: macOS

Reproduction

  1. Start Codex Desktop.
  2. Open a new/empty conversation: CPU remains normal.
  3. Open an existing large conversation/thread.
  4. Observe Codex main process CPU spikes to roughly 100%-200%.
  5. Switch to another conversation, including smaller conversations.
  6. CPU remains high until Codex Desktop is fully restarted.

Observed Details

The problematic thread file is around 501 MB and contains many saved tool results, not just regular chat text. Local inspection showed the size was mostly from persisted tool output records:

  • function_call_output: about 228 MB
  • mcp_tool_call_end: about 171 MB
  • assistant/user messages are much smaller by comparison

Cleaning the local logs database did not fix the issue. The active thread itself was small in another test case, but opening this large thread first made the whole app remain slow until restart.

Sampling the Codex Desktop main process while CPU was high showed activity concentrated around Electron/Node IPC paths, including libuv stream -> JS callback -> Buffer/memmove style work. The renderer also showed V8/renderer work during the spike.

Expected Behavior

Opening a large thread should not permanently peg CPU. If the large thread is expensive to load, Codex should either:

  • lazily load/virtualize thread history,
  • truncate or summarize persisted tool outputs in the UI,
  • avoid loading full tool output payloads unless expanded,
  • cancel/release parsing and rendering work when switching away from the thread,
  • and release memory/CPU pressure after navigating to another conversation.

Actual Behavior

After the large thread is opened once, CPU remains high even after switching away. A full app restart is required to recover.

Impact

Large long-running agent threads with many tool calls become effectively unsafe to open in Codex Desktop, because one open can make the whole app sluggish until restart.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING

codex - 💡(How to fix) Fix Codex Desktop: opening a large thread causes sustained 100%+ CPU until app restart