›_ Codex Issues
Codex Issues / #38771

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

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

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.

View original on GitHub ↗

4 Comments

github-actions[bot] contributor · 12 days ago

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

  • #38769
  • #38760
  • #38455
  • #38744
  • #38515

Powered by Codex Action

FourCLabs · 12 days ago

I am seeing what appears to be the same issue on a newer macOS build and can add a strong A/B isolation result.

Environment:

  • macOS 26.6.1 (25G76)
  • Apple Silicon / arm64
  • ChatGPT desktop app with embedded Codex
  • Embedded Codex CLI: codex-cli 0.148.0-alpha.9
  • Codex Framework observed in process output: 151.0.7922.137

Observed behavior:

  • SkyComputerUseService continuously spawns into the hundreds while Codex is open.
  • mds_stores rises to roughly 250–650%+ CPU.
  • Individual SkyComputerUseService processes have reached ~35–42% CPU.
  • macOS becomes increasingly laggy, Codex beachballs, and eventually crashes/closes on its own.
  • After Codex is completely quit, pgrep -fl SkyComputerUseService returns no results.

I also tested with a fresh ~/.codex state; the issue still reproduced.

Most useful isolation test:

With Codex quit, I ran:

killall SkyComputerUseService 2>/dev/null
rm -rf ~/.codex/computer-use
mkdir ~/.codex/computer-use
chmod 000 ~/.codex/computer-use

After reopening Codex:

  • SkyComputerUseService remained completely absent.
  • The runaway helper spawning stopped.
  • Codex remained responsive.
  • I left it running for nearly two hours without the previous catastrophic behavior.

I then restored my original ~/.codex and normal Computer Use functionality.

Immediately after reopening:

  • SkyComputerUseService began spawning repeatedly again.
  • Hundreds of instances appeared.
  • mds_stores climbed to ~382% CPU.
  • Several helpers were using ~35–42% CPU.
  • Codex subsequently crashed and closed on its own.

I can attach the process dump if useful.

codex-macos-computer-use-bug.txt

inportcoai-ai · 2 days ago

I can confirm the same failure on a newer ChatGPT/Codex Desktop build, with a controlled zero-touch reproduction and matching crash signature.

Environment

  • ChatGPT/Codex Desktop: 26.818.61809 (build 7019)
  • macOS: 26.5.1 (25F80)
  • Apple Silicon / arm64
  • Hardware: MacBookPro18,1
  • 16 GB RAM
  • Computer Use: 26.823.1000854 (build 1000854)
  • Computer Use executable:

~/.codex/computer-use/Codex Computer Use.app/Contents/MacOS/SkyComputerUseService

Controlled reproduction

Before launch:

  • SkyComputerUseService count: 0

No Computer Use task was started. Simply launching ChatGPT reproduced the issue.

Timeline (2026-08-24, CEST / UTC+02:00):

  • 18:44:44 — ChatGPT launched
  • 18:44:49 — first SkyComputerUseService appeared
  • 18:44:55 — 27 processes
  • 18:45:03 — 64 processes
  • 18:45:10 — 102 processes
  • 18:45:20 — 150 processes
  • 18:45:31 — 200 processes
  • 18:45:42 — 249 processes
  • 18:45:50 — 285 processes
  • 18:46:22 — UI unresponsive / test stopped

After force-quitting ChatGPT:

pgrep -f 'SkyComputerUseService' | wc -l
0

A process-tree capture also showed the runaway SkyComputerUseService instances as direct children of the ChatGPT process (same ChatGPT PID as PPID), rather than an independent LaunchAgent respawn loop.

Crash / hang evidence

The macOS crash report matches the signature already reported here:

  • EXC_CRASH (SIGABRT)
  • Termination Reason: SIGNAL 6 / Abort trap: 6
  • "Dispatch Thread Soft Limit Reached: 64 (too many dispatch threads blocked in synchronous operations)"
  • repeated blocked bootstrap path involving:
  • RemoteHostedPIPContentService sendBootstrapToServiceWithProcessIdentifier:rendezvousPort:attempt:
  • NSAppleEventDescriptor sendEvent...
  • AESendMessage
  • _dispatch_group_wait_slow

A later crash on 2026-08-24 at 19:29:49 +0200 again showed the dispatch-thread soft-limit condition and the same RemoteHostedPIPContentService / AppleEvents bootstrap path.

App logs near the failure also contained:

  • EPIPE / "write EPIPE"
  • app-server stdio transport stopping
  • "Failed to load the native Computer Use menu state"
  • "Worker bus disposed for 'computer-use'"

Permissions

This reproduces with the required macOS permissions already granted:

  • Screen & System Audio Recording: ChatGPT = allowed
  • Accessibility: ChatGPT = allowed
  • Accessibility: Codex Computer Use = allowed

No missing-permission condition was identified.

Additional observation

Submitting an in-app Bug feedback report while the issue was occurring was followed by another ChatGPT crash/hang. After reopening the app, the feedback submission was confirmed as uploaded.

Feedback ID:

no-active-thread-01a034d8-2c88-7461-a372-e19ea37ea92a

This appears to confirm that the same unbounded Computer Use bootstrap/helper lifecycle failure is still present in build 7019, rather than being limited to the 26.810.x builds originally reported here.

I have preserved the full macOS crash/hang reports, controlled-repro timestamps, Console evidence, and app logs locally and can provide specific sanitized excerpts if maintainers need them.

FourCLabs · 2 days ago

Follow-up with new root-cause evidence:

I asked Codex to perform a deeper local investigation of this issue.

The Mac has a case-only home-path mismatch:

  • The macOS account record and HOME value use the lowercase spelling.
  • The actual home folder on disk uses uppercase characters in the same name.
  • Both paths resolve to the same physical folder.
  • The .codex directory is not a symlink.

A direct test using the signed build-6971 native matcher returned:

  • Expected helper path using the lowercase account-record spelling: no match
  • Expected helper path using the canonical on-disk spelling: match

This suggests Codex is comparing the expected and observed SkyComputerUseService executable paths as case-sensitive strings. macOS starts the correct helper and reports its canonical path, but Codex rejects it because the capitalization differs and repeatedly launches another helper.

We tested this workaround:

CODEX_HOME=/Users/[canonical-home-folder]/.codex

When that value was present before build 6971 launched, it completed an extended supervised test involving normal typing and Computer Use activity. It maintained one unchanged helper with normal memory and thread counts.

However, after the next computer restart, build 6971 opened and the maximum-CPU/helper-spawn behavior returned. I stopped it and rolled back rather than allowing another crash.

The login environment later showed the canonical CODEX_HOME value correctly. This suggests, but does not prove, a startup-order race where ChatGPT opened before the login-time environment setting was applied. The workaround should therefore be considered partial and not reboot-reliable.

I am currently back on version 26.803.41515, build 6321, which is stable with one helper.

I do not remember changing the home-folder capitalization. It may have happened long ago during account creation, migration, restoration, or a folder rename. I plan to repair the account record separately, but macOS resolves both spellings to the same folder, so Codex should not depend on a raw case-sensitive path comparison.

Suggested upstream changes:

  • Canonicalize both executable paths before comparing them, or compare filesystem identity.
  • Limit helper startup retries and add backoff.
  • Clean up failed or superseded helpers.

The local investigation and bounded testing described above were performed by Codex. I will not intentionally reproduce the unstable build solely to collect additional evidence.