macOS app crashes while idle: computer-use threads accumulate, dispatch thread limit reached, then V8 OOM/SIGABRT #38515

What version of the Codex App are you using (From “About Codex” dialog)?

26.810.41047 (6570)

What subscription do you have?

Plus

What platform is your computer?

Darwin 25.6.0 arm64 arm

What issue are you seeing?

The ChatGPT/Codex macOS app crashes while idle, even when I am not running a Computer Use task.

The issue still occurs after:

• Reinstalling the application
• Uninstalling the Computer Use plugin
• Launching the app without starting any Computer Use or Codex task

In the crash report, a large number of threads named computer-use are created. Many of them are blocked in the same call path involving:

• AESendMessage
• NSAppleEventDescriptor sendEventWithOptions:timeout:error:
• sky.node
• RemoteHostedPIPContentService sendBootstrapToServiceWithProcessIdentifier:rendezvousPort:attempt:

macOS reports:

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

The application then terminates with:

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

The crashed V8 worker contains:

Thread 10 Crashed:: V8Worker
0   libsystem_kernel.dylib   __pthread_kill
1   libsystem_pthread.dylib  pthread_kill
2   libsystem_c.dylib        abort
3   Codex Framework          node::OOMErrorHandler(...)

A representative computer-use thread is blocked around:

Thread 123:: computer-use
0   libsystem_kernel.dylib   __ulock_wait
1   libdispatch.dylib        _dlock_wait
2   libdispatch.dylib        _dispatch_group_wait_slow
3   AE
4   AE
5   AE                       AESendMessage
6   node.napi.armv8.node     ffi_call_SYSV
7   node.napi.armv8.node
8   node.napi.armv8.node     CallFunction(...)
9   sky.node

I did not intentionally invoke Computer Use before the crash.

What steps can reproduce the bug?

1. Launch the ChatGPT/Codex macOS application.
2. Do not start any Computer Use task or other Codex task.
3. Leave the application running normally.
4. After a few minutes, the application crashes.

In the crash report I captured, the app launched at approximately 15:18:53 and crashed at 15:21:40, about 2 minutes and 47 seconds later.

The issue still reproduces after reinstalling the application and uninstalling the Computer Use plugin.

Session ID: N/A — no task/session was intentionally running.

Token limit usage: N/A.

Context window usage: N/A.

What is the expected behavior?

The application should remain running normally while idle.

Computer Use components should not continuously create or block worker/dispatch threads when no Computer Use task is active.

If a bundled Computer Use service fails to initialize, it should fail gracefully rather than accumulating blocked threads until the process reaches resource limits and aborts.

Additional information

The relevant native module appears to be bundled with the application itself:

/Applications/ChatGPT.app/Contents/Resources/native/sky.node

Therefore, uninstalling the separate Computer Use plugin does not appear to prevent the affected native component from being loaded.

The crash report contains a very large number of computer-use threads, with many blocked in the same Apple Event / sky.node call path.

System information from the crash report:

• macOS 26.6.1 (25G76)
• Mac14,3
• Apple M2
• 24 GB RAM
• ARM64

I can provide a PII-redacted full macOS crash report if needed.

Related issue: #32192 reports a similarly reproducible startup/idle V8 OOM that persists after reinstalling and clearing local state.

However, the crash signature appears different. #32192 crashes on CrBrowserMain with EXC_BREAKPOINT / SIGTRAP and a multi-GB V8 heap, while this issue crashes on a V8Worker with SIGABRT / node::OOMErrorHandler after macOS reports:

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

This crash also shows a large number of computer-use threads blocked around AESendMessage, sky.node, and RemoteHostedPIPContentService, which I do not see described in #32192.