ChatGPT / Codex for Mac "Computer Use" spawns unbounded `SkyComputerUseService` threads → CPU pegged + app aborts on launch (SIGABRT / V8 OOM)

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

26.810.52044 (build 6662) Also reproduced on the previous two builds: - 26.810.41047 (build 6570) - 26.810.50856 (build 6644) A newer build has not fixed it so far.

What subscription do you have?

plus

What platform is your computer?

No response

What issue are you seeing?

When the "Computer Use" feature is enabled, every turn spawns a SkyComputerUseService helper process. That process bootstraps itself by sending a synchronous Apple Event (AESendMessage) to a PIP/rendezvous service and then blocks forever waiting for a response that never arrives. Because it never exits, every turn spawns another one. They accumulate, each holding a V8 isolate, until the process hits the dispatch-thread soft limit (64) and then V8 runs out of memory and aborts the whole app (SIGABRT) — typically within ~2 minutes of launch.

The "CPU spike on launch" and the "app crashes on launch" symptoms are the same bug, not two separate problems.

Symptoms observed

1. Open ChatGPT (or trigger Computer Use). Within seconds, pgrep -f SkyComputerUseService | wc -l climbs from 0 → 50 → 200+ and never stops.

1. sysctl vm.loadavg spikes to 60–150 on a 12-core machine (≈5–12× overload).

1. After roughly 1–2 minutes, the app aborts. Console shows a ChatGPT (or Codex (Service)) crash report with bug_type 309.

1. In the degraded state, the app logs Sky Computer Use service startup request failed on every turn.

Crash signature (from the attached report, PID 4374)

Evidence

• Attached crash report: 106 threads total, of which ~45 are blocked on the identical sendBootstrapToServiceWithProcessIdentifier: synchronous IPC call; crash thread is the V8 OOMErrorHandler. The header explicitly states Dispatch Thread Soft Limit Reached: 64.

• Live observation across multiple occurrences: SkyComputerUseService count reached 200–400+ before the app died; vm.loadavg reached 60–150 on a 12-core CPU.

• The standalone Codex (Service) process crashes with the same signature (fresh crash report dated 2026-08-16), so this is not limited to the ChatGPT app.

Root cause analysis

1. Trigger. Each turn, ~/.codex/config.toml fires a notify hook:

   plus an [mcp_servers.computer-use] (and [plugins."computer-use@openai-bundled"]) entry whose command launches the Computer Use helper.

1. The hang. SkyComputerUseClient / SkyComputerUseService bootstraps by sending a synchronous Apple Event to RemoteHostedPIPContentService (sendBootstrapToServiceWithProcessIdentifier:rendezvousPort:attempt: → AESendMessage). In this build that IPC call blocks indefinitely and never returns, so the helper process sits on a dispatch thread forever and is never reaped.

1. The leak. Because the helper never exits, the next turn spawns another one. They accumulate. Each holds a V8 isolate, so JavaScript heap + GC pressure grow without bound.

1. The crash. Once 64+ dispatch threads are blocked in synchronous operations (Dispatch Thread Soft Limit Reached: 64), the V8 isolate hits node::OOMErrorHandler → abort() → SIGABRT. Hence "crashes on launch" is the same failure mode as "CPU pegged".

Workarounds attempted (and why they do not fully work)

Workaround | Result -- | -- Delete the bundled Codex Computer Use.app under ~/.codex/computer-use/ (then chflags uchg the parent dir to stop the app's self-repair from recreating it) | Stops the leak (sky count stays 0, app stable). Downside: Computer Use is dead and logs Sky Computer Use service startup request failed every turn. This is the only reliable mitigation. Edit ~/.codex/config.toml (set command = "/bin/false", disable [mcp_servers.computer-use] / [plugins."computer-use"], comment the notify hook) | Does not stick. The app rewrites config.toml on the next launch (self-healing config), restoring the notify hook and the mcp server entry — including on the newest build 26.810.52044. Replace / rename the SkyComputerUseService / SkyComputerUseClient binaries with a no-op | Blocked. The bundled .app and its binaries are protected by macOS (com.apple.macl / com.apple.provenance xattrs, and a uchg immutable flag on the parent directory); xattr -d / chmod / mv / rm as a normal user are denied.

Note: in config.toml, both [plugins."computer-use@openai-bundled"] and [mcp_servers.computer-use] already show enabled = false, yet the top-level notify hook still invokes SkyComputerUseClient — so disabling those sections does not stop the spawn.

Requested fix / questions

1. Please fix the RemoteHostedPIPContentService sendBootstrapToServiceWithProcessIdentifier: IPC path so it does not block synchronously forever (add a timeout / async handshake / proper cleanup of the spawned helper).

1. Please stop the unbounded accumulation: reap SkyComputerUseService when its IPC is unacknowledged, and cap concurrent helpers.

1. Is there a supported way to fully disable Computer Use that survives app relaunch (i.e., that the app's config self-healing will not re-enable)?

1. Is this specific to macOS 26 / Apple Silicon, or are Intel users affected too?

1. Which exact build carries the fix so we can verify? (Current latest, 26.810.52044 / 6662, still reproduces.)

What steps can reproduce the bug?

1. Install ChatGPT for Mac 26.810.52044 (6662) on macOS 26.6.1 (Apple Silicon).
2. Enable the "Computer Use" feature (Settings → … → Use Computer), or have a session with Computer Use enabled.
3. Launch the app / start a session.
4. Observe Activity Monitor or run:

   pgrep -f SkyComputerUseService | wc -l      # grows unbounded
   sysctl vm.loadavg                            # climbs to 60–150
   

5. Within ~2 minutes the app crashes (SIGABRT). A report like ChatGPT-2026-08-18-1331…ips is produced.

Environment commands used for verification

defaults read /Applications/ChatGPT.app/Contents/Info.plist CFBundleShortVersionString   # 26.810.52044
defaults read /Applications/ChatGPT.app/Contents/Info.plist CFBundleVersion              # 6662
sw_vers -productVersion                                                              # 26.6.1
sysctl sysctl.proc_translated                                                       # 0 (native ARM-64)
pgrep -f SkyComputerUseService | wc -l
sysctl vm.loadavg

Happy to provide full crash reports, the relevant config.toml snippets, and pgrep/vm.loadavg captures to help reproduce.

What is the expected behavior?

No response

Additional information

No response

Start with ~/.codex/config.toml and the Computer Use entry points named in the report: SkyComputerUseClient, SkyComputerUseService, and sendBootstrapToServiceWithProcessIdentifier:rendezvousPort:attempt:. Reproduce with pgrep -f SkyComputerUseService | wc -l and inspect the reported synchronous Apple Event path. Done requires preventing unbounded helper accumulation, handling an unacknowledged bootstrap, and identifying a relaunch-persistent disable or fixed build.