›_ Codex Issues
Codex Issues / #27559

Codex Desktop thread becomes extremely slow and recovers after restart

Open 💬 7 comments Opened Jun 11, 2026 by donDinDonDev
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

A Codex Desktop thread can become extremely slow/hang during normal work. Reasoning/progress updates become very delayed, and stopping/restarting the Codex app temporarily improves the behavior, but the slowdown returns later.

Feedback ID from the in-app feedback dialog: 019eb235-67aa-7b23-9d66-9b4213b63d45

Environment

  • Codex Desktop: 26.608.12217 / build 3722
  • Bundled CLI: codex-cli 0.138.0-alpha.7
  • Bundled Node: v24.14.0
  • Chromium framework: 149.0.7827.54
  • macOS: 26.5.1 (25F80)
  • Architecture: Apple Silicon / arm64
  • Memory: 8 GB

Observed behavior

  • One active thread becomes very sluggish after some time.
  • The reasoning/progress stream appears to stall or advance very slowly.
  • Restarting Codex Desktop seems to help temporarily.
  • After continuing work, the same kind of slowdown can reappear.

Local diagnostics

A process snapshot during the slowdown did not show Codex helper processes consuming high CPU at that exact moment. However, there were multiple active helper groups related to Codex/browser tooling, including processes like:

  • codex app-server --listen stdio://
  • node_repl
  • npm exec @playwright/mcp@latest
  • playwright-mcp

At the same time, some macOS system processes were relatively busy, including syspolicyd, trustd, and WindowServer.

Memory/disk notes from the same machine:

  • System memory: 8 GB
  • memory_pressure reported about 41% free memory at the sample moment, but swap activity counters were high.
  • Data volume was around 90% used, with about 44 GiB free.

Possibly related installation/signing state

This same Codex Desktop installation also reports an invalid app signature:

/Applications/Codex.app: invalid signature (code or signature have been modified)
In architecture: arm64

The app/helper entitlements also appear invalid locally:

warning: binary contains an invalid entitlements blob. The OS will ignore these entitlements.

This may or may not be related, but I am including it because the slowdown coincided with visible syspolicyd/trustd activity, and the same installation is also involved in a separate in-app Browser crash report: #27349.

Privacy note

I intentionally did not include local project names, local file paths, username, hostname, serial/UUID/UDID values, full process output, or screenshots.

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 1 month ago

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

  • #26293
  • #26327
  • #27164

Powered by Codex Action

donDinDonDev · 1 month ago

Additional live data from a recurrence after restarting Codex Desktop:

  • The app was restarted, but an active thread became very sluggish again.
  • This snapshot does not look like a simple local memory exhaustion case:
  • memory_pressure reported about 46% free memory at the sample moment.
  • state_5.sqlite: about 47 MB
  • logs_2.sqlite: about 1.7 GB
  • sessions: about 1.5 GB
  • No SkyComputerUseClient orphan accumulation was present at the sample time:
  • SkyComputerUseClient_total=0
  • SkyComputerUseClient_ppid1_orphans=0
  • Helper/process aggregates during the sluggish state:
  • codex app-server --listen stdio://: 2 processes, about 69.5 MB RSS total, 0.0% CPU at that instant
  • node_repl: 2 processes, about 14.4 MB RSS total, 0.0% CPU at that instant
  • broader Codex-related aggregate included renderer/helper/app-server/browser-tooling processes, roughly ~1.6 GB RSS total, with moderate CPU activity but no obvious runaway process
  • The local config does include a legacy notify = [..., "turn-ended"] hook pointing at SkyComputerUseClient (path redacted). That overlaps with #26293, but no SkyComputerUseClient orphans existed in this specific live snapshot.
  • Short stack samples taken during the sluggish state did not show runaway CPU:
  • app-server sample: physical footprint about 197 MB, mostly waiting on condvar/semaphore/kevent/pread paths
  • renderer sample: physical footprint about 378 MB / peak about 491 MB, mostly mach_msg/kevent/V8-related frames

So this recurrence after restart looks related to the broader Desktop responsiveness/helper lifecycle/log-state family, but it was not a direct reproduction of hundreds of SkyComputerUseClient orphans at the time sampled.

donDinDonDev · 1 month ago

Second recurrence captured after the task in the affected thread finished and the user started it again:

  • The thread became sluggish/hung again after restart/re-run.
  • Still no direct SkyComputerUseClient leak at the sample time:
  • SkyComputerUseClient_total=0
  • SkyComputerUseClient_ppid1_orphans=0
  • No orphaned codex app-server --listen stdio:// or node_repl processes in this snapshot.
  • Memory pressure still did not indicate total memory exhaustion:
  • memory_pressure reported about 40% free memory.
  • Local state sizes remained about the same:
  • state_5.sqlite: about 47 MB
  • logs_2.sqlite: about 1.7 GB
  • sessions: about 1.5 GB
  • Codex-related process aggregate during this recurrence was roughly:
  • Codex app/helper processes: 21, about 873 MB RSS total, CPU sum around 63%
  • app-server processes: 3, about 173 MB RSS total, CPU sum around 14%
  • playwright_mcp: 4, about 28 MB RSS total
  • node_repl: 2, about 8 MB RSS total

This reinforces that the slowdown is reproducible after restarting/re-running, but in these two samples it is not explained by hundreds of stale helper processes or immediate system-wide memory exhaustion.

donDinDonDev · 1 month ago

More precise local evidence tied to the affected conversation ID (019eb235-67aa-7b23-9d66-9b4213b63d45):

  • The user reports that they are not manually using the in-app Browser in this thread. The thread is normal coding work from the user's perspective.
  • Despite that, local Desktop logs for this conversation repeatedly contain IAB_LIFECYCLE entries.
  • A notable local log line for this conversation shows a completed turn being resumed/marked as streaming:
maybe_resume_success conversationId=019eb235-67aa-7b23-9d66-9b4213b63d45 latestTurnStatus=completed markedStreaming=true
  • Soon after, there are browser-route warnings for the same conversation:
IAB_LIFECYCLE browser use route window missing for cursor state ...
IAB_LIFECYCLE browser use route window missing for active state ...

This looks like a stale/inconsistent Desktop state issue: the conversation appears to have Browser/IAB route state attached even though the user is not actively using Browser in that thread, and a completed turn can be restored as markedStreaming=true. That may explain why the thread appears stuck/sluggish after restart/re-run without a clear CPU/memory runaway.

donDinDonDev · 1 month ago

Update after reinstalling Codex Desktop:

The user reinstalled Codex Desktop from a fresh app install, but the local code-signing state is still broken on the newly installed app.

Environment/build after reinstall:

  • Codex Desktop: 26.608.12217 / build 3722
  • Bundled CLI: codex-cli 0.138.0-alpha.7

Post-reinstall checks:

$ codesign --verify --verbose=4 /Applications/Codex.app
/Applications/Codex.app: invalid signature (code or signature have been modified)
In architecture: arm64
$ codesign -d --entitlements :- /Applications/Codex.app
warning: binary contains an invalid entitlements blob. The OS will ignore these entitlements.
$ spctl -a -vv /Applications/Codex.app
/Applications/Codex.app: internal error in Code Signing subsystem

codesign -dv --verbose=4 also shows:

Authority=(unavailable)
Info.plist=not bound
TeamIdentifier=2DC432GLL2
Notarization Ticket=stapled

So a normal app reinstall did not restore a valid signature/entitlements state. This may be relevant to the repeated Desktop sluggish/hung thread behavior and the related Browser/IAB crash issue.

twentyOne2x · 1 month ago

Adding a larger current-build slow-load datapoint and cross-linking #27601.

Environment:

Codex Desktop 26.608.12217 / build 3722
Bundled CLI 0.138.0-alpha.7
macOS 26.3 / Darwin 25.3.0 arm64

From one day of local Desktop logs:

thread/resume successful responses: 2464
over 30s: 411
over 60s: 103
over 120s: 16
max thread/resume duration: 260777 ms
max thread/read duration: 158955 ms
mcp_request_timeout events: 10

This matches the user-visible behavior where a thread can look blank/stuck for minutes and it is unclear whether it will eventually load. Hard quitting/reopening Codex Desktop improves the behavior temporarily, which suggests live Desktop/app-server state degradation rather than missing local thread data.

donDinDonDev · 1 month ago

Update after applying the latest Codex Desktop update:

The app updated successfully, but the local code-signing/entitlements problem still reproduces on the new build.

Version after update:

  • Codex Desktop: 26.609.30741 / build 3808
  • Bundled CLI: codex-cli 0.140.0-alpha.2
  • Chromium framework: still 149.0.7827.54

Checks after update:

$ codesign --verify --verbose=4 /Applications/Codex.app
/Applications/Codex.app: invalid signature (code or signature have been modified)
In architecture: arm64
$ codesign -d --entitlements :- /Applications/Codex.app
warning: binary contains an invalid entitlements blob. The OS will ignore these entitlements.
$ spctl -a -vv /Applications/Codex.app
/Applications/Codex.app: internal error in Code Signing subsystem

codesign -dv --verbose=4 still shows:

Authority=(unavailable)
Info.plist=not bound
TeamIdentifier=2DC432GLL2
Notarization Ticket=stapled

So the update changed the app/CLI build but did not resolve the invalid signature/entitlements state locally.