›_ Codex Issues
Codex Issues / #20435

Codex Desktop renderer spins at high CPU while codex MCP servers are idle

Resolved 💬 6 comments Opened Apr 30, 2026 by eeeepie Closed Aug 26, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

Codex Desktop appears to have a renderer CPU spin issue. A Codex Helper (Renderer) process stayed around 85-120% CPU for roughly an hour, causing a macOS laptop to heat up. Killing/restarting the helper stopped the high CPU, and the machine began cooling down immediately.

The Codex CLI and codex mcp-server processes themselves were low CPU, so this looks like a Desktop/Electron renderer issue rather than backend compute.

Environment

  • OS: macOS
  • App: Codex Desktop
  • Related setup: multiple Claude sessions configured with codex mcp-server
  • Workload: long-running Codex Desktop conversation with large outputs/tables and several background MCP server connections

Observed behavior

A Codex Desktop renderer process consumed high CPU continuously:

Codex Helper (Renderer)  ~85-120% CPU
RSS                      ~240 MB
Runtime                  ~1 hour

At the same time, related backend processes were mostly idle:

codex                    ~0.5-2% CPU
codex mcp-server          0% CPU
node codex mcp-server     0% CPU

After killing/restarting the renderer/helper process, the high CPU disappeared.

Expected behavior

The Codex Desktop renderer should not remain at high CPU while the Codex CLI and MCP server processes are idle. If there are many MCP connections, long chat history, or heavy tool output, the renderer should throttle, batch UI updates, or otherwise avoid a sustained busy loop.

Possible trigger

This may be related to one or more of:

  • Multiple Claude sessions connected to codex mcp-server
  • Several simultaneous MCP server connections
  • Long chat history / large rendered outputs
  • Continuous MCP status or tool event updates
  • Electron/React renderer repeatedly re-rendering state even when backend processes are idle

The MCP server itself did not appear to be the CPU source.

Reproduction sketch

  1. Run Codex Desktop on macOS.
  2. Configure multiple Claude sessions/processes to use codex mcp-server.
  3. Keep a long Codex Desktop conversation open with large tool outputs or tables.
  4. Let the system run for an extended period.
  5. Observe Codex Helper (Renderer) in Activity Monitor or via ps.

Suggested areas to inspect

  • Renderer update loop for MCP connection state
  • Rendering of long tool outputs / long chat histories
  • Event batching or throttling for MCP status updates
  • Handling of detached or idle MCP connections
  • Possible React/Electron re-render loop triggered by multiple MCP clients

If this repo is not the right place for Codex Desktop issues, please route or close with the right tracker.

View original on GitHub ↗

6 Comments

github-actions[bot] contributor · 3 months ago

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

  • #19942
  • #19665
  • #19568
  • #19916

Powered by Codex Action

lmac-oai · 3 months ago

+1
/feedback trace:
2e5ae587-2f13-4fdd-8e7b-0048ea00e492

lmac-oai · 3 months ago

Adding a more specific root-cause data point from a recurrence on macOS with Codex Alpha Desktop.

The hot process was again the Electron renderer, not the agent backend:

Codex (Alpha) Helper (Renderer)  ~114% CPU
codex app-server                 ~14% CPU during startup/backfill, then idle
Codex (Alpha) main process        low single digits
active codex CLI session          normal

What looked causal in this reproduction:

  • The app logs repeatedly reported:
  • state db backfill not complete at /Users/lmac/.codex (status: pending)
  • large startup payloads, including thread/list around 1.7 MB and app/list around 714 KB
  • Local session history under ~/.codex/sessions was about 1.0 GB total:
  • 2026/04: ~704 MB
  • 2026/03: ~204 MB
  • 2026/02: ~119 MB
  • 2026/01: ~32 MB
  • total rollout count observed: 211
  • Reauth/sign-in did not fix the CPU spin.
  • Resetting Desktop app state/cache alone did not permanently fix it; after sign-in the renderer went hot again.

Mitigation that did fix it locally:

  1. Quit/kill the Codex Alpha Desktop process tree.
  2. Quarantine older local session history, leaving the active current-day CLI session in place:
  • moved ~/.codex/sessions/2026/01 through 2026/04 aside
  • moved ~/.codex/archived_sessions aside
  1. Relaunch Codex Alpha.

After that, live ~/.codex/sessions dropped from roughly 1.0 GB to about 15 MB. On relaunch, the renderer stayed near 0.1% CPU and app-server stayed near 0% after startup. The app was still able to run with the current-day session preserved.

There were also stale auth/plugin warnings in the fresh logs:

  • Linear MCP invalid_token
  • one invalid_grant: Invalid refresh token
  • unsupported feature enablement workspace_dependencies
  • mcpServerStatus/list took about 19s once at startup

Those warnings appear worth cleaning up, but they did not correlate with the sustained renderer spin after the session-history/backfill load was removed. The strongest root-cause hypothesis from this repro is: large local session history triggers expensive state DB backfill / thread indexing / renderer hydration on Desktop startup, and the renderer can get stuck in a sustained high-CPU state while processing that state.

Suggested areas to inspect:

  • state DB backfill over large ~/.codex/sessions trees
  • thread list/sidebar hydration when many or very large rollouts are present
  • renderer-side processing of large thread/list results
  • cancellation/backoff/progress behavior for pending backfill
  • whether old archived sessions should be excluded, capped, lazily indexed, or processed outside the renderer-critical startup path

No raw logs attached here because the local logs may contain sensitive paths/auth context, but I can provide targeted excerpts if useful.

h12613 · 3 months ago

I want to upvote this issue. Codex is using pretty crazy amount of CPU 61% on M5 Pro even when it's idle.
Feedback id: 019deb4d-0626-7a13-8ef2-055bd70c3294
It should include the cpu usage informaiton.

Necmttn · 2 months ago

A useful diagnostic would split renderer work from agent/backend work.

When CPU stays high, collect renderer route/view, visible message count, pending MCP connection count, last render cause, transcript size, and app-server activity. If MCP servers are idle, the report should make that clear so the investigation stays on rendering, polling, or virtualization.

---

_Generated with ax._

etraut-openai contributor · 2 days ago

Note: We've announced that the mcp-server is deprecated and will be removed in a future release. We recommend using the app server interface instead. We won't be prioritizing any bug fixes in the mcp-server, so I'm going to close this issue.