Skip to content

Codex Desktop thread becomes extremely slow and recovers after restart #27559

Open
Open
Codex Desktop thread becomes extremely slow and recovers after restart#27559
Labels
appIssues related to the Codex desktop appbugSomething isn't workingperformance

Description

@donDinDonDev
donDinDonDev
opened on Jun 11, 2026

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.

Activity

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

  2. github-actions commented on Jun 11, 2026

    @github-actions
    github-actionsbot
    on Jun 11, 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. donDinDonDev commented on Jun 11, 2026

    @donDinDonDev
    donDinDonDev
    on Jun 11, 2026 – with ChatGPT Codex Connector
    Author

    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 SkyComputerUseClient processes spawned for turn-ended events remain alive as PPID=1 orphans #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.

  4. donDinDonDev commented on Jun 11, 2026

    @donDinDonDev
    donDinDonDev
    on Jun 11, 2026 – with ChatGPT Codex Connector
    Author

    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.

  5. donDinDonDev commented on Jun 11, 2026

    @donDinDonDev
    donDinDonDev
    on Jun 11, 2026 – with ChatGPT Codex Connector
    Author

    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.

  6. donDinDonDev commented on Jun 11, 2026

    @donDinDonDev
    donDinDonDev
    on Jun 11, 2026 – with ChatGPT Codex Connector
    Author

    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.

  7. twentyOne2x commented on Jun 11, 2026

    @twentyOne2x
    twentyOne2x
    on Jun 11, 2026

    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.

  8. donDinDonDev commented on Jun 11, 2026

    @donDinDonDev
    donDinDonDev
    on Jun 11, 2026 – with ChatGPT Codex Connector
    Author

    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.

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