[macOS] ChatGPT 26.818.41705 still enters unbounded SkyComputerUseService spawn storm, freezes Mac, and crashes

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

• #38841
• #39151
• #38760
• #38771
• #39403

Powered by Codex Action

I can confirm the same issue on another Mac, including the same crash signature.

Environment:

ChatGPT: 26.818.41705 (6971)
macOS: 27.0 (26A5416b)
Apple Silicon / ARM64

The issue reproduces simply by launching ChatGPT and leaving it idle. I do not need to invoke Computer Use.

Activity Monitor shows ChatGPT Computer Use processes being created continuously. I confirmed that the actual executable is:

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

All instances have the main ChatGPT process as their direct parent. In one observation, the process count increased as follows:

01:08:30 — 26
01:08:32 — 34
01:08:34 — 40
01:08:36 — 48

I also moved ~/.codex/computer-use aside and relaunched ChatGPT to rule out stale/corrupted local Computer Use state. The issue reproduced again immediately.

The macOS crash report shows:

Triggered by Thread: 320 computer-use
Exception Type: EXC_CRASH (SIGABRT)
Dispatch Thread Soft Limit Reached: 64 (too many dispatch threads blocked in synchronous operations)
Application Specific Information: abort() called

I also observed multiple threads blocked in synchronous Apple Event operations involving AESendMessage, NSAppleEventDescriptor sendEventWithOptions:timeout:error:, and RemoteHostedPIPContentService.

This looks like the same unbounded SkyComputerUseService spawn/retry loop described in this issue.

One additional data point: this reproduces on macOS 27.0, whereas the original report is on macOS 26.5.2, so the issue does not appear to be limited to a single macOS major version.

I have the full .ips crash report and an Activity Monitor screenshot showing the process spawn storm if those would be useful.

I can confirm that the same unbounded SkyComputerUseService spawn issue still occurs in the newer 26.818.61809 build (7019).

I also found an environment condition that reliably triggers the issue, along with a working workaround.

Environment

• ChatGPT / Codex Desktop: 26.818.61809 (build 7019)
• Last known-good version: 26.803.61601
• macOS: 26.4.1 (25E253)
• Hardware: Mac16,8
• Architecture: Apple Silicon / ARM64
• Bundle ID: com.openai.codex

My Codex home directory is a symbolic link:

$HOME/.codex -> /Volumes/data/proj/codex_data

Trigger condition

When CODEX_HOME is not already present in the GUI user's launchd environment and 26.818 is launched normally from Finder, the Computer Use PiP bootstrap repeatedly fails.

The macOS unified log repeatedly reports the following error for the SkCu/PiPB AppleEvent:

paramErr (-50)

Instead of stopping or applying retry backoff, the application continuously creates new Computer Use helpers and workers.

One crash report shows:

• Exception: EXC_BREAKPOINT / SIGTRAP
• ESR: (Breakpoint) brk 0
• Approximately 326 total threads
• 186 threads named computer-use
• Faulting thread: computer-use
• Stack frames involving RemoteHostedPIPContentService, V8/Node memory allocation, and garbage collection

This appears consistent with the helper/process spawn storm and Computer Use thread crashes described in this issue.

Differential test

| Startup condition | Connected to CUAService | paramErr (-50) | Helper behavior |
| --- | ---: | ---: | --- |
| Normal startup using the symlinked path | 0 | 24–28 within approximately 12 seconds | Continuously created |
| CODEX_HOME set to the physical path | 1 | 0 | At most one new helper |

With the physical path, the log reports a successful connection:

RemoteHostedPIPContent connected to CUAService

Version 26.803.61601 also connects successfully on the same machine with the same symbolic link, helper location, account, and macOS permissions.

Fully quitting the older version and confirming that SkyComputerUseService had exited did not change the behavior of 26.818. This rules out a helper process left behind by the older version.

Setting the physical path only in config.toml was not sufficient. The environment variable must be present before the application starts, suggesting that the PiP/helper bootstrap occurs before this configuration is loaded.

Workaround

Set CODEX_HOME to the physical target of the symbolic link before launching ChatGPT:

launchctl setenv CODEX_HOME /Volumes/data/proj/codex_data

Then fully quit and restart ChatGPT 26.818.

If $HOME/.codex is a symbolic link, the following can also be added to $HOME/.zprofile:

if [[ -L "$HOME/.codex" ]]; then
    codex_home_real="$(cd -P "$HOME/.codex" 2>/dev/null && pwd -P)"

    if [[ -n "$codex_home_real" ]] &&
       [[ "$(/bin/launchctl getenv CODEX_HOME)" != "$codex_home_real" ]]; then
        /bin/launchctl setenv CODEX_HOME "$codex_home_real"
    fi

    unset codex_home_real
fi

Note that .zprofile is only evaluated when a zsh login shell starts. After logging out or restarting macOS, Terminal must be opened once before launching ChatGPT.

Possible root cause

At least in my environment, this appears to be a path-canonicalization regression introduced after 26.803. During the Computer Use PiP bootstrap, 26.818 seems to mix the logical $HOME/.codex path with the physical target of the symbolic link.

The application should canonicalize CODEX_HOME, the Computer Use helper path, and related bootstrap parameters before performing the PiPB handshake.

The bootstrap failure path should also enforce a retry limit, exponential backoff, and a helper process cap so that a single paramErr cannot escalate into unbounded process and thread creation.

Confirmed on a newer build with a matching failure signature and additional IPC/path evidence.

Environment

• ChatGPT/Codex app: 26.818.61809 (build 7019)
• Earlier crashes also reproduced on 26.818.21641 (build 6849)
• Computer Use helper: 26.823.1000854
• macOS 15.6.1 (24G90), Darwin 24.6.0, Apple Silicon arm64
• 36 GB RAM, 14 logical CPUs
• Bundle ID: com.openai.codex

Reproduction and crash evidence

Seven matching macOS crash reports were generated between 10:15 and 10:37 CST on August 25, 2026. The failure survived an app update from 26.818.21641 to 26.818.61809.

At failure, the ChatGPT process consistently had:

• 320–326 total threads
• 185–186 threads named computer-use
• EXC_CRASH / SIGABRT with node::OOMErrorHandler(...) -> abort(), or EXC_BREAKPOINT / SIGTRAP on the same Node/V8 worker/isolate path

The unified macOS log showed the bootstrap/IPC loop immediately before the process storm:

invalid capability attempting to make send right on port (... dead:1 ...)
Error processing AppleEvent, err=-50
CUAService bootstrap failed

The failing code identity path was:

/Volumes/CodexVolatileRAM/computer-use/Codex Computer Use.app/Contents/MacOS/SkyComputerUseService

During one approximately 80-second observation window, the log contained 439 unique SkyComputerUseService PIDs. At least 266 instances reached normal termination while ChatGPT continued launching replacements. This strongly indicates an unbounded bootstrap retry/reuse loop rather than a single helper crash.

This was not system-wide memory pressure: there were no memory-pressure, jetsam, or system OOM events in the failure windows. The machine still had substantial available memory during inspection. The helper also passed strict code-signature and Gatekeeper validation.

Isolation result

I moved ~/.codex/computer-use to a reversible backup location and allowed the app to recreate it. The recreated helper had the same version and identical SHA-256 hashes, ruling out binary corruption.

After recreation:

• The live helper executed directly from ~/.codex/computer-use/... rather than the volatile RAM volume.
• Only one SkyComputerUseService process remained active.
• The main app stabilized at 58 threads instead of more than 320.
• No dead-port retry loop appeared.
• No additional crash reports were generated during an observation period exceeding the previous crash interval by more than four times.

The path-dependent behavior suggests that the service bootstrap/reuse logic should be inspected for stale Mach/AppleEvent endpoints or LaunchServices registration associated with CodexVolatileRAM. A failed bootstrap needs deduplication, bounded retries with backoff, a process cap, and cleanup of the corresponding computer-use worker/V8 isolate.

Raw .ips reports and sanitized unified-log excerpts are available if maintainers need a specific sample.

@rick147's differential test matches a six-condition matrix I posted in #38769, and I think I can supply the piece nobody in either thread has stated yet: why the symlinked spelling makes the handshake fail, at the code level. Cross-linking so the two threads don't diverge.

Where the mismatch is created

From app.asar: when SKY_CUA_SERVICE_PATH is set, it is returned verbatim and un-normalized, and then used as expectedExecutablePath in

computerUseServiceProcessMatchesExecutablePath(pid, expectedExecutablePath)

which the CUA manager consumes as isExpectedServiceProcess. The expected path is assembled as serviceAppPath/Contents/MacOS/SkyComputerUseService.

The AppleEvent itself is sent from Contents/Resources/native/sky.node, which imports both posix_spawn and proc_pidpath — consistent with "spawn the helper, read the PID's executable path, compare it to the expected path". proc_pidpath returns the resolved path (/Volumes/...), while expectedExecutablePath retains the symlink spelling ($HOME/.codex/...). Those two strings can never be equal, so the identity/readiness check fails on every attempt, the PID is discarded, and another helper is spawned — with no readiness wait, no backoff, no single-flight, and no cap.

This is why paramErr (-50) here and procNotFound (-600) in my case are both downstream symptoms rather than the cause: the app is asking about a PID it has already decided isn't its service.

It is also why this is not a TCC or LaunchServices problem — the AppleEvent targets a PID directly instead of resolving a bundle URL, and tccd logged zero denials for com.openai.sky.CUAService across 20 minutes of continuous storming on my machine.

There is a second un-normalized use worth checking too: the "canonical refresh" step dittos the source service into ${CODEX_HOME}/computer-use/Codex Computer Use.app without canonicalizing first.

Reconciling the three independent reports

| Source | Symlinked | Canonicalized |
|---|---|---|
| @rick147 (this thread) | 0 connections, 24–28 paramErr in ~12 s, helpers created continuously | 1 connection, 0 errors, at most one helper |
| #38769 (mine, 6 configs × 6 min) | crash in 126–158 s, 385–434 helpers | exactly 1 helper, stable |
| @iuxxoo (#38769) | — | 1 helper, stable through real Computer Use calls |

One apparent discrepancy is worth stating precisely, because it affects the workaround instructions people are copying:

• @rick147 found that setting the physical path only in config.toml was not sufficient, and concluded the bootstrap runs before config load.
• My matrix found that setting the environment variable only, while config.toml still carried symlinked paths, avoided the crash but still leaked a finite number of helpers at startup (61) before going flat.

Both results are consistent with: the env var must be present before launch and is what prevents the storm, while the remaining config paths account for a bounded startup leak. So the safe instruction is to do both, env var first, then relaunch — not either one alone.

Regression boundary

@rick147's observation that 26.803.61601 connects successfully on the same machine, same symlink, same helper location, same permissions is the most useful single data point in this thread for whoever picks it up: the symlink did not change, the app's handling of it did. Consistent with that, my first crash occurred about two minutes after an auto-update landed 26.810.52044, on a symlink layout that had been in place and working for weeks beforehand.

The part that isn't about symlinks

@brian-wijaya reported in #38769 that their helpers were dying with their own SIGABRT in __assert_rtn / IOSurface initialization, on a setup where paths were not the issue. A helper that dies during startup for any reason fails the same readiness check and enters the same retry loop — so path identity is one reliable entry point, not the only one.

Their other observation is the sharpest structural evidence available: killing all 343 helpers produced exactly 343 replacements. A one-for-one replacement means the desktop process is retaining one restart controller per failed helper, which is precisely the missing single-flight guard, and it explains why killing children never recovers the app.

For whoever picks this up

The two fixes are separable, and the second one is the one that bounds the blast radius regardless of trigger:

1. Canonicalize once at the process boundary, or compare stable file/code identity instead of path strings.
2. One in-flight spawn attempt, an explicit readiness wait before the first AppleEvent, bounded exponential backoff, a process cap, and a circuit breaker.

With (2) alone — even leaving the path comparison exactly as it is — every report in this thread would degrade from "app consumes several GB, freezes the Mac, and aborts in 90–158 s" into a logged, recoverable handshake failure.

Worth noting that neither [plugins."computer-use@openai-bundled"] enabled = false nor [mcp_servers.computer-use] enabled = false stops the managed service, and the app rewrites the Computer Use notify hook back into config.toml on every launch, so affected users currently have no supported way to opt out while waiting for a fix.

Related: #38769, #38697.

Additional data point: the reversible ~/.codex/computer-use reset did not resolve the issue on my machine.

Further testing caused the entire Mac to become unresponsive and reboot at approximately 10:19 JST on Aug 27. I stopped testing to avoid repeated host-level failures.

After reboot, the installed app is 26.803.41515 (build 6321). Its desktop log repeatedly records Browser Use runtime initialization followed by:

heartbeat_automation_resume_failed
invalid thread/session id: "thread"

At the current observation there is only one SkyComputerUseService process, so recreating the helper can change the process count but does not reliably eliminate the underlying failure path.

No kernel-panic report was retained in the standard DiagnosticReports directory, so I cannot confirm whether the reboot was a kernel panic, watchdog event, or an extreme-load reset.

Still reproduces on app 26.820.60940 (build 7119) with Computer Use helper 26.819.1000816 (@oai/sky 0.6.21) — newer than the builds in this thread. It took the whole machine down via a kernel panic tonight.

Two things I can add that I haven't seen pinned down yet: a different helper crash signature from #38697's SIGSEGV, and the specific system resource that runs out and turns a helper crash-loop into a full OS reboot.

Environment

• ChatGPT desktop 26.820.60940 (build 7119), bundle ID com.openai.codex
• Helper com.openai.sky.CUAService 26.819.1000816
• macOS 26.6.2 (25G83), Darwin 25.6.0 — MacBook Pro Mac17,9 (M5 Pro), 48 GB
• Incident 65EBE98C-5C65-4C5C-89DE-44BC66E4EA6F
• App was idle, display asleep (displayState: OFF). Computer Use was not invoked manually.

Helper crash signature — SIGABRT, not SIGSEGV

Each helper lives ~15s (procLaunch 23:14:10 → crash 23:14:25) and aborts on an assertion while building its first NSWindow:

EXC_CRASH (SIGABRT) — Abort trap: 6
  abort
  __assert_rtn
  ___ioSurfaceConnectInternal_block_invoke.cold.1
  _ioSurfaceConnectInternal
  IOSurfaceClientGetPropertyMaximum
  __NSWindowResolvedScaleFactor_block_invoke
  NSWindowResolvedScaleFactor
  -[NSWindow _commonInitFrame:styleMask:backing:defer:]
  -[NSWindow initWithContentRect:styleMask:backing:defer:]
  SkyComputerUseService

parentProc: ChatGPT, coalitionName: com.openai.codex. This is a failed IOSurface connection, distinct from the _XXMIGPostNotification segfault in #38697. Since it happened with the display asleep, an NSWindow created while no display is awake looks like a plausible trigger — the helper asserts instead of handling the failure.

Respawn rate: the PID space wraps

Unified log, consecutive helper launches:

22:55:07.626  SkyComputerUseService[443]
22:55:57.085  SkyComputerUseService[10840]

~208 processes/second. Between 22:55 and 23:14 the machine burned through the entire PID space and wrapped at least once. There is no backoff at all.

The actual kill mechanism: launchservicesd dispatch-pool exhaustion

This is the part I think is missing from the existing reports. From the watchdog stackshot:

• 934 live SkyComputerUseService processes, 7,745 threads, 29.88 GB resident (coalition total 31.47 GB of 48 GB; system-wide RSS 49.98 GB, ~300 MB free)
• launchservicesd (pid 145) carries flag exceededWQTotalLimit with 513 threads, 512 of them parked on "queue thread to be allocated" — it hit the libdispatch worker-thread ceiling and deadlocked
• 445 threads system-wide blocked on it, 423 of them SkyComputerUseService
• WindowServer then blocks during startup: turnstile blocked on task pid 145, hops: 3 (com.apple.coreservices.launchservicesd)

Every helper launch registers with LaunchServices, so 200 spawns/sec saturates that daemon. Once it deadlocks, WindowServer cannot complete initialization, and the userspace watchdog escalates:

panic(cpu 1): userspace watchdog timeout: no successful checkins from
WindowServer (2 induced crashes) in 150 seconds
  is_alive_func returned unhealthy :
  WindowServer initialization not complete (post IOKitWaitQuiet)

So the reboot is not memory pressure and not a WindowServer bug — it is PID/LaunchServices exhaustion starving a watchdog-monitored service. That also explains why reports here describe a hard reboot rather than an OOM kill.

Corroborating, once the system was saturated the helpers could no longer even take power assertions:

SkyComputerUseService[39025] (IOKit) IOPMAssertionCreateWithProperties:
  io_pm_assertion_create failed with error 0xe00002bd
SkyComputerUseService[39025] [inc.software.app:Computer Use]
  Computer Use display sleep prevention — SystemSoftware.PowerAssertion.Error

Note each spawn also created and immediately released a PreventUserIdleDisplaySleep / UserIsActive assertion named "Codex Computer Use interaction", ~200×/second.

The loop survives a reboot

After the panic and restart, the storm resumed immediately — 343 more spawns at 23:19–23:20 — because the app relaunched on login. That makes this hard to escape without uninstalling; the machine re-enters the loop before you can quit the app.

Suggested fixes

1. Bound the respawn — exponential backoff plus a circuit breaker (e.g. stop after N failures in M seconds). This alone downgrades the bug from "reboots the Mac" to "Computer Use is unavailable".
2. Don't assert on IOSurface failure — IOSurfaceClientGetPropertyMaximum failing with the display asleep should be a handled error, not __assert_rtn.
3. Don't create an NSWindow at helper startup when there is no work and no awake display.