›_ Codex Issues
Codex Issues / #38744

ChatGPT desktop app (26.810.52044) crash loop: OOM abort in "computer-use" worker + 64 dispatch threads blocked in RemoteHostedPIPContentService bootstrap

Resolved 💬 4 comments Opened Aug 15, 2026 by akoken Closed Aug 15, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Environment

  • App: ChatGPT desktop (merged Codex app), version 26.810.52044 (build 6662), bundle id com.openai.codex
  • Codex Framework: 151.0.7922.137
  • macOS: 26.5.2 (25F84), Mac14,13 (Apple Silicon, ARM64)

Summary

The app crashes reliably ~90 seconds after every launch. No user-initiated
computer-use/agent task exists; the crash happens during the app's own
startup restore. 10+ identical crashes over 2 days, reproducible across
reinstall, fresh local state, permission resets, and a reboot.

Crash signature

EXC_CRASH (SIGABRT), triggered by thread named computer-use
(a Node worker inside Codex Framework):

Thread 317 Crashed:: computer-use
0 libsystem_kernel.dylib __pthread_kill + 8
1 libsystem_pthread.dylib pthread_kill + 296
2 libsystem_c.dylib abort + 148
3 Codex Framework node::OOMErrorHandler(char const*, v8::OOMDetails const&) + 344
...
(deep JS recursion: 12+ elided recursion levels through the same frame,
then node::worker::MessagePort::OnMessage -> uv_run -> worker::Run)

Additionally the report shows:

Dispatch Thread Soft Limit Reached: 64 (too many dispatch threads blocked in synchronous operations)

with 60+ dispatch threads all blocked in the same synchronous Apple Event send:

AESendMessage
-[NSAppleEventDescriptor sendEventWithOptions:timeout:error:]
sky.node: -[RemoteHostedPIPContentService sendBootstrapToServiceWithProcessIdentifier:rendezvousPort:attempt:]

So the PIP content service bootstrap hangs, dispatch threads pile up to the
soft limit, and the computer-use worker dies on V8 heap OOM with what looks
like runaway recursion.

What I ruled out

Each attempt reproduced the identical crash signature:

  1. Full uninstall + reinstall of the app.
  2. Killing leftover helper processes from the pre-merger Codex.app bundle

(they were still running from the deleted bundle and sharing
~/Library/Application Support/Codex).

  1. Deleting ~/Library/{Application Support,Caches,HTTPStorages}/com.openai.codex.
  2. tccutil reset ScreenCapture|Accessibility|AppleEvents com.openai.codex

(and not re-granting).

  1. Moving ~/Library/Application Support/Codex/codex-browser-app and

browser-sidebar-*.json aside — the app recreated them fresh and crashed
identically, so corrupted local state is excluded.

  1. Full macOS reboot.

Crash report

  • Incident: 3A5F59B4-8DEF-4920-B257-0C69E6AFE260 (2026-08-15 10:34 +0300)
  • Latest recurrence: 2026-08-15 13:29 +0300 (fresh local state)
  • Full .ips available on request; can also share via Feedback Assistant ID

if preferred.

Possibly related: #28274 (Computer Use helper issues), #38037 (post-merger
launch crash loop, different signature).

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 13 days ago

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

  • #38515
  • #38455

Powered by Codex Action

skalacademy · 13 days ago

I am experiencing what appears to be the same or a closely related macOS Codex desktop issue.

Environment

macOS Tahoe 26.6.1
Apple Silicon / arm64
Previous affected ChatGPT/Codex app version: 26.810.50856
Current version: 26.810.52044
I confirmed through the built-in updater that 26.810.52044 is currently the newest version available to me.

Issue

Codex has been increasingly unstable for approximately the past week. Initially, a long-running Codex conversation became extremely slow and repeatedly displayed:

Context automatically compacted

This occurred multiple times in succession while Codex was attempting to continue working. Eventually the desktop application became unstable enough that it began terminating unexpectedly.

The application can sometimes remain open normally while sitting idle on the home screen. However, attempting to actually use Codex triggers the problem. I have reproduced failures by:

Opening/resuming my existing Codex conversation
Clicking New Chat
Attempting to continue work in the existing project

On at least one occasion, simply clicking New Chat caused the application to crash before I could type anything.

When the application crashes, I receive:

ChatGPT stopped unexpectedly

Restart ChatGPT to continue. If the problem persists, check your configuration or visit the documentation.

Restarting the application does not resolve the issue.

Behavior after latest update

I was previously experiencing these crashes on version 26.810.50856. I then updated to 26.810.52044 and confirmed that the built-in updater reports it as the newest version available.

The issue still occurs on 26.810.52044.

I am now also receiving a more specific error when attempting to resume my existing Codex conversation:

Failed to resume chat

Codex app-server is not available

The Codex UI itself loads and displays the existing conversation, but the conversation cannot resume because the Codex app-server reports as unavailable.

Diagnostics available

macOS Console generated Codex-specific diagnostic reports during the affected period, including reports from:

August 13, 2026 at approximately 10:21 PM
August 14, 2026 at approximately 6:27 AM

The reports are .diag performance/diagnostic reports for the codex process on arm64. I have retained the original files and can provide them privately or attach sanitized copies if a maintainer requests them.

I am intentionally not attaching screenshots or raw diagnostic files publicly because they may contain device/account-identifying information.

Please let me know if there are specific log entries, diagnostic fields, or other non-sensitive information from these reports that would help isolate the failure.

akoken · 12 days ago

Closing as a duplicate of #38455 — same signature (SIGABRT via node::OOMErrorHandler on the computer-use worker, dispatch thread soft limit 64 with threads blocked in RemoteHostedPIPContentService bootstrap).

One additional confirming data point for that thread: the reversible containment described there works on my machine too (app 26.810.52044, macOS 26.5.2). Removing the app-written notify turn-ended hook from config.toml, setting [features] computer_use = false, and moving the Computer Use runtime directory aside stopped the spawn storm; the app has been stable since, with Computer Use intentionally unavailable. Note the app re-adds the notify hook to config.toml on every launch, as reported in #38455 — the containment holds only because the hook's target binary no longer exists.

xxarupakaxx · 12 days ago

I can independently reproduce what appears to be the same failure on ChatGPT Desktop 26.810.52044 (build 6662) on macOS.

Observed symptoms:

  • ChatGPT/Codex crashes after showing Dispatch Thread Soft Limit Reached.
  • ps aux | grep -Ei 'ChatGPT|Codex' | grep -v grep | wc -l returned 319 processes.
  • syspolicyd did not appear to be the source of the exhaustion in this reproduction: ~2.5% CPU, 0.1% memory, and only 36 open files when checked.
  • The installed app is /Applications/ChatGPT.app, not a standalone Codex.app.
  • The bundle contains Codex components including:
  • /Applications/ChatGPT.app/Contents/Resources/native/codex-macos
  • Codex Framework.framework version 151.0.7922.137
  • Codex (GPU), Codex (Service), Codex (Alerts), and Codex (Renderer) helpers.
  • The process list showed many long-lived browser_crashpad_handler processes using ~/Library/Application Support/Codex/Crashpad, plus many bare-modifier-monitor processes accumulated across launches.

App version:

CFBundleShortVersionString: 26.810.52044
CFBundleVersion: 6662

This looks consistent with an unbounded helper/worker lifecycle issue rather than Gatekeeper / syspolicyd exhaustion.

I have not yet collected a full .ips crash report or a time-series of SkyComputerUseService counts, but the process count reaching 319 and the identical desktop build / dispatch-thread warning appear to corroborate this issue. I can collect additional diagnostics if maintainers want a specific command or crash artifact.