ChatGPT 26.810.52044 repeatedly launches SkyComputerUseService until macOS lags and the app OOM-crashes

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

ChatGPT/Codex Desktop 26.810.52044 (build 6662)

The currently installed rollback is 26.810.50856 (build 6644), but the five matching crash reports below were captured on build 6662.

What subscription do you have?

Paid individual ChatGPT plan (local Codex plan type reports prolite).

What platform is your computer?

Darwin arm64 arm

• macOS 26.5 (25F71)
• Apple Silicon
• Hardware model: Mac17,2

What issue are you seeing?

The desktop app repeatedly launches new SkyComputerUseService processes while no Computer Use task is running. The population grows without bound, makes the whole Mac severely laggy through CPU, memory, and process pressure, and then ChatGPT aborts.

I captured five separate matching Apple crash reports on build 6662. Their common signature is:

• EXC_CRASH / SIGABRT
• triggered computer-use worker around thread 319–321
• Dispatch Thread Soft Limit Reached: 64
• about 187 computer-use threads
• node::OOMErrorHandler(...) -> abort()
• repeated blocked path:
  RemoteHostedPIPContentService sendBootstrapToServiceWithProcessIdentifier:rendezvousPort:attempt:
-> NSAppleEventDescriptor sendEventWithOptions
-> AESendMessage

A live bounded observation showed ChatGPT launching approximately one new SkyComputerUseService every 0.3 seconds. More than 100 direct children accumulated; individual helpers were commonly around 50–90 MB RSS. Disabling the Computer Use runtime startup path stopped new launches. Terminating only the verified Computer Use child processes reduced their count to zero and the ChatGPT app remained running.

This is not ordinary resource use from an active Computer Use task. It is an unbounded helper/bootstrap lifecycle loop.

What steps can reproduce the bug?

1. Start ChatGPT Desktop normally.
2. Do not start a Computer Use task; the failure also occurs while the app is idle.
3. Monitor direct child processes belonging to ChatGPT.
4. Observe new SkyComputerUseService instances appearing roughly every 0.3 seconds.
5. Continue observing as helper count, CPU use, memory use, and computer-use threads increase.
6. The Mac becomes increasingly unresponsive.
7. ChatGPT eventually aborts with V8 OOM and the dispatch-thread soft-limit signature above.

The failure reproduced repeatedly across five ordinary launches on build 6662.

What is the expected behavior?

ChatGPT should have one bounded owner for the Computer Use service, reuse a running or initializing service, and apply bounded retries/backoff if bootstrap fails. Leaving the app idle must not create an unlimited number of helpers or degrade the whole operating system.

Additional information

This closely matches #38455 and #38744. I am filing this report because it adds a clean process-level observation on build 6662:

ChatGPT
└─ repeated SkyComputerUseService direct children

The evidence supports a failed service bootstrap/reuse lifecycle: ChatGPT continuously decides another Computer Use helper is needed, blocked bootstrap attempts accumulate, system resources are exhausted, and V8 aborts.

A related clue, not presented as the proven cause: this machine's ~/.codex is a symlink. #25269 reports a different Computer Use multi-helper routing failure involving a symlinked ~/.codex. However, the crash signature here matches #38455 much more closely, and other users reproduced that issue after clearing ~/.codex, so the symlink should be treated only as a test variable.

A sixth crash report from a deliberately restricted diagnostic launch is excluded because it failed during HIServices registration and does not have the Computer Use/OOM signature.

Raw crash reports are preserved locally. I can provide narrowly requested, sanitized excerpts or a bounded process trace if a maintainer specifies what is needed.

Start by reproducing the idle-launch loop on ChatGPT Desktop 26.810.52044 and inspect the Computer Use runtime startup path and SkyComputerUseService lifecycle. Compare the process behavior with #38455 and #38744, paying attention to the RemoteHostedPIPContentService bootstrap path and treating the symlinked ~/.codex only as a test variable. Done means idle launches remain bounded and failed bootstrap attempts do not accumulate helpers, exhaust resources, or trigger OOM.