ChatGPT Desktop 26.810.50856 crashes after 1–3 minutes — computer-use / sky.node thread exhaustion

ChatGPT Bugs
,
1

Hi everyone,

I’m trying to determine whether anyone else is experiencing this issue with the new ChatGPT Desktop app on macOS.

Since updating to the new unified ChatGPT Desktop app, the application repeatedly crashes and completely exits approximately 1–3 minutes after launch.

The crash is highly reproducible. It can happen even if I simply launch ChatGPT and leave it idle without using Computer Use or the built-in browser.

Environment

  • macOS: 26.5.2 (25F84)
  • Apple Silicon / ARM64
  • ChatGPT Desktop: 26.810.50856 (Build 6644)
  • Bundle ID: com.openai.codex

The same problem also occurred on the previous version I had installed:

  • 26.810.41047 (Build 6570)

So the issue has persisted across at least two builds.

Crash report

The latest macOS .ips crash report shows:

Triggered by Thread: 318  computer-use

Exception Type: EXC_CRASH (SIGABRT)
Termination Reason: Namespace SIGNAL, Code 6, Abort trap: 6

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

Application Specific Information:
abort() called

A large number of threads appear to become blocked in the same path:

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

The crash report also contains multiple V8 worker threads involving:

reading_mode$cxxbridge1$194$parse_distilled_html

Steps to reproduce

  1. Launch ChatGPT Desktop.
  2. Leave the application running.
  3. No interaction with Computer Use or the built-in browser is required.
  4. After approximately 1–3 minutes, the entire ChatGPT process exits.
  5. macOS generates a new .ips crash report.

This has happened repeatedly.

Troubleshooting already attempted

I have tried:

  • Completely quitting and restarting ChatGPT.
  • Clearing all built-in browser data.
  • Launching ChatGPT and leaving it completely idle.
  • Reinstalling/testing different versions.
  • Updating from Build 6570 to Build 6644.

The problem still occurs.

The optional Browser extension shown in ChatGPT Settings is not installed, but the crash is still triggered by the computer-use thread.

I also tested the older ChatGPT Classic client (com.openai.chat), which uses a different runtime.

Current status

I have already submitted this to OpenAI Support and the case has been escalated to a support specialist.

I have complete macOS .ips crash reports available, but I’m posting the relevant crash signature here to see whether anyone else can reproduce the same issue.

Is anyone else on macOS seeing crashes involving computer-use, sky.node, RemoteHostedPIPContentService, or “Dispatch Thread Soft Limit Reached: 64”?

2

Same crash here on Build 6662 — and I think the actual abort is a V8 heap OOM, not the dispatch-thread limit.

Environment

  • macOS 26.5.2 (25F84), Apple Silicon
  • ChatGPT Desktop 26.810.52044 (Build 6662)
  • That makes at least three affected builds: 6570 → 6644 → 6662.

The faulting frame is the V8 OOM handler

In my .ips reports the crashing frames are:

__pthread_kill
pthread_kill
abort
node::OOMErrorHandler(char const*, v8::OOMDetails const&)

The crashing thread is named computer-use, and its full stack bottoms out in:

node::worker::Worker::Run()
node::SpinEventLoopInternal(node::Environment*)
uv_run / uv__io_poll
node::worker::MessagePort::OnMessage(...)
v8::Function::Call(...)
node::builtins::BuiltinLoader::CompileFunction(...)

So these are Node.js worker threads named computer-use, each carrying its own V8 isolate, spawned continuously and never torn down. Dispatch Thread Soft Limit Reached: 64 looks like a symptom of the same leak rather than the cause — the process dies in the V8 OOM handler.

Measured growth (sampled every 10s from launch)

elapsed RSS threads
8s 1.4 GB 107
18s 0.8 GB 168
28s 1.6 GB 195
38s 2.3 GB 222
48s 3.1 GB 248
58s 3.9 GB 274
69s 4.6 GB 299
79s 5.3 GB 322
89s 5.9 GB 345
~90s crash

Linear: roughly 2.5 threads/sec and ~70 MB/sec, with no plateau. At crash time the .ips shows 187 threads named computer-use, 152 of them parked in _dispatch_group_wait_slow.

Across 17 crashes over three days, time-to-crash was consistently 70–114 seconds, idle, with no interaction at all.

It is not caused by local state

I isolated it in three steps:

  1. Disabled the computer-use@openai-bundled plugin → crashed at 89s.
  2. Moved the Codex Computer Use.app binary out of CODEX_HOME entirely → crashed at 89s.
  3. Pointed CODEX_HOME at a brand-new empty directory — no sessions, no config, no plugins, no auth → crashed at 89s with an identical curve.

Step 3 is the decisive one: with zero local state the app still spawns the same worker storm, so this is in the shipped app rather than in anyone’s profile.

Worth noting that [mcp_servers.computer-use] enabled = false was set in my config the entire time and the leak still occurs, so that switch does not gate whatever is spawning these workers.

Workaround

None found for the GUI. The bundled codex CLI (ChatGPT.app/Contents/Resources/codex) is unaffected and runs normally, so agent work can continue from the terminal. ChatGPT Classic (com.openai.chat) is stable but has no agent features.

Happy to share full .ips files if that helps narrow it down.

3

Thanks — this is extremely helpful and matches my crashes very closely.

I’m also on macOS 26.5.2 (25F84), Apple Silicon.

I reproduced the issue repeatedly on:

  • 26.810.41047 (Build 6570)
  • 26.810.50856 (Build 6644)

My .ips reports also show the crash being triggered by the computer-use thread, with SIGABRT, node::OOMErrorHandler, and Dispatch Thread Soft Limit Reached: 64.

Your thread/RSS measurements and clean CODEX_HOME test are particularly interesting. They would explain why clearing browser data and reinstalling did not change the behavior on my machine.

I have already opened a case with OpenAI Support and it has been escalated to a support specialist. I’ll add this information to the case, especially that the same issue is still reproducible on Build 6662.

One thing we have in common that may be worth highlighting: we’re both running exactly macOS 26.5.2 (25F84) on Apple Silicon.

If anyone can reproduce this on a different macOS build, that would help determine whether this is specific to 26.5.2 or a general Desktop runtime regression. I can confirm the memory growth on my machine as well. When I launched the Desktop GUI today, macOS displayed the “Your system has run out of application memory” warning, and ChatGPT had grown to over 16 GB of memory usage before I had to force quit it.

The Codex CLI itself is currently working normally for me. The excessive memory usage only occurs when the ChatGPT Desktop GUI (com.openai.codex) is running.

This seems consistent with your V8/computer-use worker leak analysis

4

Thanks for the additional details — this is very helpful.

5

I just reproduced it again on 26.810.52044 (Build 6662).
Interestingly, this crash ended as EXC_BREAKPOINT (SIGTRAP) instead of SIGABRT, but it was still triggered by the computer-use thread and still reported Dispatch Thread Soft Limit Reached: 64.
The stack still contains repeated sky.node -> RemoteHostedPIPContentService -> sendBootstrapToServiceWithProcessIdentifier calls, so the underlying worker/thread leak appears unchanged.

6

Hi.

I had the same issue for days… reinstalled, nothing worked.
Today on a hunch i opened it and before it could crash i went to connections and removed the other machines i would access from the crashing app. I quit and restarted. I did not remove remote control of the crashing app, FYI.

So far… been about an hour. no crashes yet.

Hope this helps someone.

7

Update — workaround has been stable for 24+ hours

I have an update: after making the changes below, ChatGPT Desktop has now been running for more than 24 hours without a single crash.

Before this, the crash was extremely reproducible — the Desktop app would usually terminate within roughly 1–3 minutes of launch, across multiple builds.

What I changed:

  • Explicitly disabled computer_use
  • Confirmed the Computer Use plugin was not installed
  • Removed the notify callback from my Codex configuration
  • Completely moved the local Computer Use state directory out of the way:
~/.codex/computer-use

I renamed it to:

~/.codex/computer-use.disabled-cua-crash-20260822
  • Fully quit ChatGPT with Cmd+Q and restarted it

After that, the Desktop app stopped crashing. It has now remained stable for 24+ hours, compared with the previous 1–3 minute time-to-crash.

I haven’t restored the computer-use directory or re-enabled Computer Use yet.

So I would consider this a confirmed workaround on my machine, but not yet a confirmed root cause, since I changed several Computer Use-related things at the same time.

This is also interesting in light of the other report above where removing previously connected machines under Connections stopped the crashes. Both workarounds may be affecting persisted Computer Use / remote-hosted state.

Given that my previous crash reports repeatedly contained:

computer-use

sky.node

RemoteHostedPIPContentService

it seems increasingly likely that the crash is related to some Computer Use / remote-hosted state or initialization path.

For now I’m leaving the working configuration untouched. If I later isolate which specific change fixes it, I’ll update this thread.

8

I did my workaround (above yours) and it was fine until Computer Use was turned on… then it went to crashing.
I think both the C Use and the Remote connections are causing this issue, seemingly independently.