Codex Desktop sluggish after today's update to 26.429.20946

[najibninaba]

What happened?

After updating Codex Desktop today, May 1, 2026, the app feels noticeably more sluggish than it did before the update. General UI interactions are less responsive, and the regression was apparent immediately after updating.

Before the update, the same app/workflow felt much more responsive on this machine.

Performance trace

I recorded and uploaded a performance trace as instructed by the app:

43b31e53-6359-468e-89ff-a73a240ecf72

Environment

• Codex Desktop: 26.429.20946 (2312)
• macOS: 26.4.1 (25E253)
• Device: MacBook Pro Mac15,8
• Chip: Apple M3 Max
• Memory: 64 GB

Expected behavior

Codex Desktop should remain as responsive as it was before the update, especially for normal UI interactions.

Actual behavior

After the latest update, the app feels sluggish during normal use.

Notes

This may be related to other recent Codex Desktop performance reports, but I’m filing this with the uploaded trace ID so the team can inspect the specific capture from this machine.

[github-actions]

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

• Please also make performance improvements on Windows #20525
• Codex Desktop freezes when opening mini/popout windows; image-heavy histories are much worse than long text-heavy sessions #20544

Powered by Codex Action

[naes993]

Sidebar flickering on M1 Max as well.

Screen.Recording.2026-04-30.at.10.06.06.PM.mov

[Peddle]

it's borderline unusable on my M3 Max. Is there an archive of old desktop builds somewhere so I can revert?

[WhiteMac]

Same. CPU usage is through the roof with persistent 200% CPU pressure on my M4 MacBook Pro with the latest update.

[zoeytabmedia]

Adding another datapoint from macOS.

Environment:

• Codex Desktop macOS app
• Bad build observed: 26.429.30905 / build 2345
• Rollback build that fixed it for me: 26.422.71525 / build 2210
• macOS: 26.5 beta (25F5068a)
• Hardware: Apple Silicon / arm64

Symptoms:

• UI became extremely sluggish after the update.
• Hover/click/window-switch feedback could lag by ~20-60 seconds.
• Waiting 1-2 minutes after startup sometimes made it temporarily smooth again.
• Switching windows / focus changes could make it slow again.
• Cmd+Q sometimes did not fully quit Codex; it left the app/update state stuck.

What I checked:

• Cleaned up old active threads and rotated large logs. This helped a little, but did not fix the core issue.
• Temporarily disabled all MCP servers. No meaningful improvement.
• Tried chronicle = false. This appeared to help at first, but the lag still returned, so Chronicle was not the full root cause.
• The main recurring signal was renderer CPU, not app-server CPU.

Process evidence while sluggish:

• Codex Helper (Renderer) repeatedly hit around 120-150% CPU.
• codex app-server was usually mostly idle or much lower after startup.
• A macOS sample of the hot renderer showed time mostly in V8 / JavaScript microtasks / JIT / GC-ish paths rather than MCP/network/app-server work.
• Renderer memory footprint reached ~2.3GB in one sample.

Update/downgrade notes:

• Downgrading to 26.422.71525 made the app usable again.
• Later, clicking update from the app did download/stage 26.429.30905, but Sparkle got stuck with .sessionInProgress == YES and left Autoupdate/Updater processes around. Manually clearing the stale updater processes and applying the staged app bundle completed the update.

My read: this looks like a renderer/UI performance regression in the 26.429.x line, possibly amplified by macOS 26.5 beta and/or large active app state. The app-server did not look like the primary bottleneck during the worst UI lag.

[zoeytabmedia]

Follow-up: after reinstalling/updating back to 26.429.30905, the app exited by itself. This produced a Crashpad minidump rather than a normal macOS .ips crash report.

Crashpad dump path locally:

~/Library/Application Support/Codex/Crashpad/completed/99a16fbe-e1e7-4e94-af0b-08421793134f.dmp

Relevant strings from the dump:

out of memory
electron.v8-oom.location
electron.v8-oom.is_heap_oom
Scavenge 3415.3 (3521.6) -> 3399.0 (3507.9) MB ... allocation failure
Scavenge 3400.6 (3509.5) -> 3398.9 (3507.9) MB ... allocation failure
Scavenge 3398.9 (3507.9) -> 3399.0 (3507.9) MB ... allocation failure

So this looks stronger than just UI sluggishness: on my machine, 26.429.30905 can drive the Electron/V8 heap to roughly ~3.5GB and then OOM/exit. The earlier renderer CPU spikes and 20-60s UI stalls appear to be the lead-up to that memory blow-up.

macOS logs around the exit also showed process death for Codex and AMFI: Denying core dump for pid ... (Codex), which explains why I did not get a normal macOS DiagnosticReports .ips file.

[willtmc]

I'm seeing the same regression on a newer 26.429 build, severe enough that typing has a very pronounced delay and the desktop app is effectively unusable.

Environment:

• Codex Desktop: 26.429.30905 (2345)
• Codex CLI: codex-cli 0.128.0
• macOS: 26.4.1 (25E253)
• Machine: MacBook Pro Mac16,8
• Chip: Apple M4 Pro, 14 cores
• Memory: 24 GB

Symptoms:

• Text input lag is very noticeable (multi-second feeling / enough to make normal typing painful).
• Renderer process spikes immediately after launch around 130–150% CPU and grows to roughly 1–1.6 GB RSS.
• The delay remains even after waiting for startup to settle.

Things tried; none fixed it:

• Fresh reinstall through codex app after moving /Applications/Codex.app aside.
• Cleared Electron app state: ~/Library/Application Support/Codex.
• Moved Codex state/log DBs aside: ~/.codex/state_5.sqlite*, ~/.codex/logs_2.sqlite*, session_index.jsonl.
• Launched with minimal ~/.codex/config.toml (no plugins/MCP/large project list; memories and chronicle disabled).
• Tried launching with GPU disabled; this made it worse (main process pegged at ~100% CPU).
• Opened a normal repo workspace instead of $HOME; still bad.

I captured a macOS sample of the hot renderer. The hot path is in Electron/V8 JavaScript/microtasks/compilation, not SQLite or filesystem I/O. Representative top of sample:

Call graph:
3394 Thread_... DispatchQueue_1: com.apple.main-thread
+ 3394 v8::Context::FromSnapshot(...)
  + 3394 v8::Isolate::GetDataFromSnapshotOnce(...)
    + 3394 v8::ScriptCompiler::ScriptStreamingTask::Run()
      + 3367 v8::MicrotasksScope::PerformCheckpoint(...)
      + ... repeated V8 / microtask / optimizing compile frames ...

This survived reinstall and minimal config, so it looks like an app/runtime regression in the 26.429 desktop train rather than local state corruption.