Skip to content

Codex Desktop sluggish after today's update to 26.429.20946 #20547

Open
Open
Codex Desktop sluggish after today's update to 26.429.20946#20547
Labels
appIssues related to the Codex desktop appbugSomething isn't workingperformance

Description

@najibninaba
najibninaba
opened on May 1, 2026

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.

Activity

  1. github-actions
    added
    bugSomething isn't working
    appIssues related to the Codex desktop app
    on May 1, 2026

  2. github-actions commented on May 1, 2026

    @github-actions
    github-actionsbot
    on May 1, 2026 – with GitHub Actions
    Contributor

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

    Powered by Codex Action

  3. naes993 commented on May 1, 2026

    @naes993
    naes993
    on May 1, 2026

    Sidebar flickering on M1 Max as well.

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

  4. Peddle commented on May 1, 2026

    @Peddle
    Peddle
    on May 1, 2026

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

  5. WhiteMac commented on May 1, 2026

    @WhiteMac
    WhiteMac
    on May 1, 2026

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

  6. zoeytabmedia commented on May 3, 2026

    @zoeytabmedia
    zoeytabmedia
    on May 3, 2026

    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.

  7. zoeytabmedia commented on May 3, 2026

    @zoeytabmedia
    zoeytabmedia
    on May 3, 2026

    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.

  8. etraut-openai
    added
    performance
    on May 3, 2026

  9. willtmc commented on May 4, 2026

    @willtmc
    willtmc
    on May 4, 2026

    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.

  10. chenyanchen commented on May 6, 2026

    @chenyanchen
    chenyanchen
    on May 6, 2026

    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.

  11. zoeytabmedia commented on May 6, 2026

    @zoeytabmedia
    zoeytabmedia
    on May 6, 2026

    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 😄

  12. SleepAviator commented on Jun 2, 2026

    @SleepAviator
    SleepAviator
    on Jun 2, 2026

    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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    appIssues related to the Codex desktop appbugSomething isn't workingperformance

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions