codex - 💡(How to fix) Fix Codex Desktop 26.506.31421 main Electron process pegs ~280% CPU on macOS while app-server is idle [1 comments, 2 participants]

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…
GitHub stats
openai/codex#22053Fetched 2026-05-11 03:20:05
View on GitHub
Comments
1
Participants
2
Timeline
7
Reactions
0
Timeline (top)
labeled ×4commented ×1cross-referenced ×1subscribed ×1

On macOS, Codex Desktop 26.506.31421 (Electron 41.2.0) can drive the main Electron process to sustained ~264–285% CPU for many hours while the underlying codex app-server process stays effectively idle (~0–1% CPU). The hot path captured via sample(1) is in libuv stream reads / Node StreamBase JS callbacks with heavy Buffer/ArrayBuffer allocation, which strongly suggests the cost is in the desktop client's IPC/log/history processing rather than in model or backend compute. Restarting the app temporarily clears the main-process pegging but renderers remain unusually busy (~11% / 4.8% / 4.6%).

This appears related to (but distinct from) several existing reports; filing with concrete sample/profile evidence in case it helps narrow the root cause.

Error Message

Live process snapshot before restart (uptime of main process ~23h38m):

Root Cause

This appears related to (but distinct from) several existing reports; filing with concrete sample/profile evidence in case it helps narrow the root cause.

Code Example

uv__io_poll
  -> node::LibuvStreamWrap::OnUvRead
    -> node::StreamBase::CallJSOnreadMethod
      -> V8 / JS frames
        -> heavy Buffer / ArrayBuffer allocation
        -> _platform_memmove, __bzero
RAW_BUFFERClick to expand / collapse

Codex Desktop 26.506.31421 main Electron process pegs ~280% CPU on macOS while app-server is idle

Summary

On macOS, Codex Desktop 26.506.31421 (Electron 41.2.0) can drive the main Electron process to sustained ~264–285% CPU for many hours while the underlying codex app-server process stays effectively idle (~0–1% CPU). The hot path captured via sample(1) is in libuv stream reads / Node StreamBase JS callbacks with heavy Buffer/ArrayBuffer allocation, which strongly suggests the cost is in the desktop client's IPC/log/history processing rather than in model or backend compute. Restarting the app temporarily clears the main-process pegging but renderers remain unusually busy (~11% / 4.8% / 4.6%).

This appears related to (but distinct from) several existing reports; filing with concrete sample/profile evidence in case it helps narrow the root cause.

Environment

  • Codex Desktop: 26.506.31421 (CFBundleVersion 2620)
  • Electron: 41.2.0 (from crashpad annotation)
  • OS: macOS 26.4.1 (25E253), Darwin 25.4.0
  • Hardware: Mac mini, Apple M4, 10 cores, 16 GB RAM
  • ~/.codex/sessions: 596 MB, with individual rollout JSONL files of 178M, 65M, 64M, 62M, 46M, 23M

Observed behavior

Live process snapshot before restart (uptime of main process ~23h38m):

ProcessCPURSS
Codex.app/Contents/MacOS/Codex (main, PID 665)264–285%1.35–1.52 GB
Codex Helper (GPU)16–24%
Codex Helper (Renderer, one of several)13–21%~1.9 GB footprint
codex app-server0.1–1.3%

After a full app restart:

  • Main process drops near idle.
  • Renderers still show abnormal steady-state activity (~11%, 4.8%, 4.6%) without user interaction.

High-signal evidence

sample(1) of the main process shows the hot path concentrated in Electron/Node's local stream pipeline:

uv__io_poll
  -> node::LibuvStreamWrap::OnUvRead
    -> node::StreamBase::CallJSOnreadMethod
      -> V8 / JS frames
        -> heavy Buffer / ArrayBuffer allocation
        -> _platform_memmove, __bzero

Concurrent log patterns (repeating at high frequency):

  • AppServerConnection response routing for thread/list, skills/list, mcpServerStatus/list.
  • browser-session-registry IAB_LIFECYCLE duplicate route captures.
  • Received turn/started for unknown conversation.
  • Repeated git status / git rev-parse probes against saved workspace roots; several roots are Git repos with "No commits yet on main" / no HEAD, causing git rev-parse to return exit code 128 in a tight loop.

Local samples available (no secrets):

  • /tmp/codex-main-665.sample.txt
  • /tmp/codex-renderer-1485.sample.txt
  • /tmp/codex-gpu-975.sample.txt

Why this looks client-side, not model/backend compute

  • codex app-server CPU is ~0–1% throughout, while the Electron main process is at ~280%. If the cost were model/tool execution, the app-server (or a tool subprocess) would show it.
  • The sampled hot stack is purely libuv stream read → Node StreamBase JS callbacks → Buffer allocations and memmove/bzero, i.e. IPC/stream-decode work in the desktop client.
  • Memory footprint and uptime correlate: the longer the app runs and the larger ~/.codex/sessions grows, the worse it gets; restart resets main-process CPU.
  • Log volume is dominated by client-side housekeeping (sidebar lists, lifecycle dedupe, git polling) rather than turn execution.

Possible contributing factors / related issues

These look plausibly connected; not claiming any are the root cause:

  • Large local rollout history. ~/.codex/sessions at 596 MB with multiple 50–180 MB JSONL files seems likely to amplify any per-startup or per-list scan. See #18693 (open: large local histories causing desktop performance collapse).
  • Sidebar / workspace git polling against repos without a HEAD. Saved roots with "No commits yet on main" produce repeated git rev-parse exit-128s. See #19115 (closed as duplicate: non-git saved workspace roots / git warning loops).
  • Prior high-CPU reports on macOS with similar magnitudes:
    • #18467 ("~276% CPU" on macOS; closed, but later commenters reproduced).
    • #18481 (duplicate high CPU / overheating).
  • Possibly related but unconfirmed: #21911 mentions a feature-negotiation mismatch in 26.506.31421 (unsupported feature requests). The Received turn/started for unknown conversation and duplicate IAB_LIFECYCLE route captures here may or may not be the same surface — flagging without overclaiming.

Expected behavior

  • Idle/steady-state main-process CPU should be low (single digits) when no turn is active, regardless of session-history size or how long the app has been running.
  • Workspace roots without a Git HEAD should not trigger a tight loop of git rev-parse failures; failed probes should back off or be cached.
  • Sidebar list endpoints (thread/list, skills/list, mcpServerStatus/list) should not generate sustained stream traffic sufficient to peg the Node event loop.
  • Duplicate IAB_LIFECYCLE route captures and turn/started for unknown conversation warnings should not occur in steady state.

Attachments available

Happy to share on request:

  • sample(1) output for main, renderer, and GPU helper processes (paths above).
  • Redacted excerpts of the AppServerConnection / browser-session-registry / git-probe log loops.
  • ls -lhS ~/.codex/sessions summary (sizes only, no content).

Let me know what additional captures (e.g. --cpuprof of the main process, heap snapshot of a renderer) would be most useful and I can attach them.

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…

FAQ

Expected behavior

  • Idle/steady-state main-process CPU should be low (single digits) when no turn is active, regardless of session-history size or how long the app has been running.
  • Workspace roots without a Git HEAD should not trigger a tight loop of git rev-parse failures; failed probes should back off or be cached.
  • Sidebar list endpoints (thread/list, skills/list, mcpServerStatus/list) should not generate sustained stream traffic sufficient to peg the Node event loop.
  • Duplicate IAB_LIFECYCLE route captures and turn/started for unknown conversation warnings should not occur in steady state.

Still need to ship something?

×6

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

Back to top recommendations

TRENDING