Codex Desktop sluggish after today's update to 26.429.20946

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

• #20525
• #20544

Powered by Codex Action

Sidebar flickering on M1 Max as well.

https://github.com/user-attachments/assets/5720f845-51cf-46b2-b93f-7a92c60bb71e

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

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

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.

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.

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.

Additional datapoint on a newer 26.429 desktop build.

Environment:

• Codex Desktop: 26.429.61741 (2429)
• Bundled Codex CLI: codex-cli 0.128.0-alpha.1
• Electron: 41.2.0 (from Crashpad process annotation)
• macOS: 26.4.1 (25E253)
• Platform: Darwin 25.4.0 arm64 arm
• Hardware: Mac16,12, Apple M4, 32 GB RAM

Observed behavior:

At 2026-05-06 19:00 +0800, Activity Monitor showed a sustained hot renderer. The process had been running for about 7.5 hours and did not drop back to idle:

PID   Process                  CPU       RSS/Memory      Elapsed
1742  Codex                    ~0.1%     ~413 MB RSS     07:32:28
1787  codex app-server         ~11.5%    ~220 MB RSS     07:32:27
1951  Codex Helper (Renderer)  ~100.5%   ~742 MB RSS     07:32:27

top -l 3 -s 2 -pid 1951 showed the renderer still hot on repeated samples:

Codex Helper (Renderer)  72.6%  39:39.93  23/1 threads  693M
Codex Helper (Renderer)  95.9%  39:41.92  23/1 threads  694M

ps -M -p 1951 showed one renderer thread running at about 99.2% CPU.

I captured a 10 second macOS sample of the hot renderer. Header:

Analysis of sampling Codex Helper (Renderer) (pid 1951) every 1 millisecond
Process:         Codex Helper (Renderer) [1951]
Identifier:      com.openai.codex.helper
Version:         26.429.61741 (2429)
Code Type:       ARM64
Parent Process:  Codex [1742]
Date/Time:       2026-05-06 19:02:26.472 +0800
Launch Time:     2026-05-06 11:32:45.284 +0800
OS Version:      macOS 26.4.1 (25E253)
Physical footprint:         694.1M
Physical footprint (peak):  793.1M

Representative stack shape from the sample:

Thread_... DispatchQueue_1: com.apple.main-thread
  ElectronMain
    v8::Context::FromSnapshot(...)
      v8::Isolate::GetDataFromSnapshotOnce(...)
        node::inspector::InspectorSocket::Shutdown(...)
          v8::ScriptCompiler::ScriptStreamingTask::Run()
            v8::internal::compiler::CompilationDependencies...
            v8::MicrotasksScope::PerformCheckpoint(...)
            v8::Function::Call(...)
            <unknown JIT frames>

DedicatedWorker thread
  v8::MicrotasksScope::MicrotasksScope(...)
    _v8_internal_Node_Print(...)
      node::inspector::InspectorSocket::Shutdown(...)
        v8::ScriptCompiler::ScriptStreamingTask::Run()
          v8::internal::compiler::CompilationDependencies...

The "Sort by top of stack" section was dominated by mach_msg2_trap, kevent64, and many <unknown binary> JIT addresses, with V8/Electron frames such as v8::Value::IsObject, v8::SharedMemoryStatistics, v8::internal::compiler::CompilationDependencies::Commit, and v8::internal::OptimizingCompileInputQueue::Prioritize.

I also checked for signals from some related issues. There were no matches in the Codex app support directory or today's Codex app logs for:

stable-metadata
Not a git repository
worker_rpc_response_error
thread-stream-state-changed
state db backfill
composing running thread resume response

Local session history size at the time was:

~/.codex/sessions           420M
~/.codex/archived_sessions   37M

Unified log error/fault entries directly from Codex in the preceding 2 hours were mostly repeated:

FSFindFolder failed with error=-43
nw_connection_copy_protocol_metadata_internal on unconnected nw_connection
Sparkle update check timeout to persistent.oaistatic.com/codex-app-prod/appcast.xml

I did not see a renderer crash/fault in the sample window. vmmap -summary 1951 reported physical footprint around 692.3M, peak 793.1M; it could not fully inspect Chromium PartitionAlloc because vmmap wanted arm64e while the Electron framework binary is arm64.

Expected behavior:

When no visible agent work or local build/test process is active, the Desktop renderer should return to low CPU instead of keeping one core saturated indefinitely.

I kept the full local sample output and can provide a more targeted excerpt if useful.

I believe this UX has been solved with the latest update, would be very nice to see the real shift to Swift instead of Codex as an Electron app tho 😄

Same here. The typing experience is a disaster. Feels like remote controlling a desktop on the moon, at least 2 seconds delay. It's even worse than the time when macOS retired the private API that Electron used and massive apps became less responsive.