[Bug] Computer Use spawn storm exhausts launchservicesd and triggers WindowServer watchdog kernel panic on macOS 26.5

Summary

The ChatGPT desktop app / Codex on macOS repeatedly spawned SkyComputerUseService at approximately 5-8 processes per second immediately after app launch. The services were not reused or cleaned up. This caused two separate failure modes:

The desktop app accumulated roughly 340 threads and crashed from a V8/Node OOM after about 60-80 seconds.
More than 500 GUI helper instances exhausted launchservicesd's dispatch-thread hard limit (512). WindowServer then failed its watchdog check-ins and macOS kernel-panicked and rebooted.

This happened twice. Computer Use was not actively being invoked when the spawn storm began.

The only effective local mitigation has been to prevent the Computer Use runtime from being installed/launched. That keeps Codex stable but makes Computer Use unavailable, so it is not an acceptable long-term resolution.

Please treat this as a critical desktop stability issue because it can reboot the host Mac and cause loss of unsaved work.

Environment

Device: Apple Silicon Mac
macOS: 26.5 (25F71)
First affected desktop build: 26.810.41047 (6570)
Reproduced after updating to build 6644
Current desktop build: 26.810.52044 (6662)
Computer Use runtime: 26.812.1000717 (1000717)
Computer Use bundle ID: com.openai.sky.CUAService

The current build still enters ensureServicePidForEnabledFeatures and logs a managed-service reconciliation failure while the runtime is intentionally blocked. I have not unlocked the runtime to reproduce on build 6662 because two previous tests caused kernel panics.

Timeline and observed impact

App launch: helper spawn storm begins within seconds.
Spawn rate: approximately 5-8 SkyComputerUseService processes per second.
Around 60 seconds: app reaches roughly 337 threads / 6 GB RSS.
Around 62-79 seconds: app crashes with V8 OOM.
518 distinct Computer Use service PIDs were present in the WindowServer spin evidence.
launchservicesd reached its dispatch-thread hard limit of 512.
WindowServer stopped checking in, was killed twice by watchdog, and could not reinitialize.
macOS kernel-panicked and rebooted twice.

Local artifacts:

26 ChatGPT/Codex crash reports after the initial event and controlled reproductions.
2 full kernel panic reports.
4 WindowServer userspace watchdog spin reports.

Raw reports can be provided through a private OpenAI support channel if requested. They are not attached publicly because the spin reports contain a full local process inventory and paths.

Desktop app crash signature

All sampled app crashes shared the same pattern:

exception: EXC_CRASH / SIGABRT (some later reports were SIGTRAP)
faulting thread: computer-use or V8Worker
node::OOMErrorHandler(char const*, v8::OOMDetails const&)
185-188 computer-use threads
approximately 138 threads blocked in AESendMessage waits

Representative blocked path:

__ulock_wait
_dispatch_group_wait_slow
AESendMessage
ffi_call_SYSV
sky.node N-API callback

Managed service failure

The desktop log repeatedly reported:

Failed to reconcile managed Computer Use service
appshotsEnabled=true
computerUseEnabled=true
errorMessage="Failed to spawn managed Computer Use service"
at ensureServicePidForEnabledFeatures

In a sanitized sample, the first two helpers started only about 149 ms apart while the first instance was still performing startup work. More helpers continued at roughly the same interval.

Each helper emitted repeated macOS runtime diagnostics during startup:

This method should not be called on the main thread as it may lead to UI unresponsiveness.

The messages were emitted from security/privacy-related initialization. This suggests the desktop service manager is starting another instance before the previous instance can finish registration and report availability.

There was no matching Gatekeeper/amfid signature-denial event in the original failure window.

AppleEvent failure

Every failing helper eventually logged an AppleEvent reply failure:

returned -609 for event SkCu/PiPB to ChatGPT
Error #17 (os/kern) invalid right attempting to add send right
dead:1

The bridge uses CodexComputerUseNativeBridge-1 and synchronous AESendMessage(..., kAEWaitReply, ...).

My current working hypothesis is a lifecycle race rather than a missing libuv run loop: multiple concurrently launched service instances supersede or invalidate the pending rendezvous/reply state, so older instances attempt to reply to ports the desktop app has already discarded.

Kernel panic / system evidence

The panic string was:

userspace watchdog timeout: no successful checkins from WindowServer
WindowServer initialization not complete (post IOKitWaitQuiet)

The corresponding WindowServer spin report begins with:

Processes reached dispatch thread hard limit (512): launchservicesd

The report contained 8,978 references to SkyComputerUseService and 518 distinct service PIDs. Kernel panic memory statistics showed no swap or compressor exhaustion, so memory pressure was not the direct panic path. The direct path was LaunchServices exhaustion followed by WindowServer watchdog failure.

Reproduction

This was reproducible on the affected machine by:

Allow the normal Computer Use runtime to exist under the Codex home directory.
Launch the ChatGPT desktop app / Codex.
Do not invoke Computer Use; simply observe processes after launch.
Within approximately five seconds, multiple SkyComputerUseService processes begin spawning.
Without a safety monitor, the app crashes in about one minute and the OS can subsequently reboot.

I do not recommend reproducing without a separate watchdog that terminates the test after more than 2-3 concurrent service instances.

Mitigations tested

Did not resolve the problem:

Updating desktop build 6570 to 6644.
Hiding Computer Use Picture in Picture.
Setting the bundled Computer Use plugin to disabled; the app restored it to enabled.
Deleting the Computer Use runtime; the app automatically reinstalled it.
Disabling the MCP entry alone.

Effective safety mitigation:

Block the Computer Use runtime directory so the app cannot reinstall or start the helper.
The app then logs one reconciliation warning per session instead of entering the spawn loop.
No further app crashes or kernel panics have occurred while the runtime remains blocked.

This mitigation disables Computer Use and therefore only protects the machine; it does not restore the feature.

Requested fixes

Please prioritize the following:

Add a process-global single-flight/in-progress guard around managed Computer Use service startup.
Enforce a hard maximum of one active/starting service instance.
Add bounded retry with exponential backoff and a circuit breaker; never retry several times per second.
Cancel and reap failed/superseded helpers and pending AppleEvent requests.
Move slow security/privacy initialization off the helper's main thread where possible.
Ensure the desktop app honors a supported Computer Use disabled state without automatically reinstalling or re-enabling it.
Add a regression test that simulates slow helper startup and verifies no second instance is launched.
Identify the first desktop/runtime build containing the fix so the blocked runtime can be restored safely.

I can validate a candidate fix with a strict process-count watchdog and provide redacted crash, panic, spin, and unified-log excerpts through a private OpenAI support channel.

Related issues

Codex for macOS accumulates Computer Use / MCP helper processes and unreaped zombie children, causing HID lag and WindowServer/TCC stalls #25744 - Computer Use / MCP helper accumulation and WindowServer/TCC stalls
Computer Use crashes SkyComputerUseService when inspecting Outlook on macOS #20683 - -609 connectionInvalid from Computer Use
[Bug] Computer Use causes a replayd XPC reconnect loop and ~90% CPU while idle on macOS #37420 - Computer Use/replayd reconnect loop
macOS Computer Use leaks SkyComputerUseClient turn-ended helpers #29157 - turn-ended Computer Use helper leak

This report adds the previously unreported escalation from helper accumulation to launchservicesd's 512-thread hard limit and an actual WindowServer watchdog kernel panic.

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

[macOS] SkyComputerUseService build 26.812.1000717 segfaults at launch; unbounded respawn storm forces WindowServer watchdog reboots of the entire Mac #38697
ChatGPT desktop 26.810.41047 repeatedly spawns Computer Use workers and crashes with V8 OOM on macOS #38455
macOS 26.810.50856: dozens of ChatGPT Computer Use processes spawn while idle, causing near-100% CPU and severe system lag #38720
macOS app crashes while idle: computer-use threads accumulate, dispatch thread limit reached, then V8 OOM/SIGABRT #38515
ChatGPT desktop app (26.810.52044) crash loop: OOM abort in "computer-use" worker + 64 dispatch threads blocked in RemoteHostedPIPContentService bootstrap #38744

Powered by Codex Action

Follow-up observation from current build 26.810.52044 (6662): Computer Use is not completely unavailable while the downloaded/managed runtime remains blocked.

There appear to be two distinct launch paths:

The desktop-managed background path attempts service reconciliation at app startup (ensureServicePidForEnabledFeatures) and uses the downloaded Computer Use runtime. This is the path that entered the rapid spawn loop in the original incident. It remains blocked locally, and the desktop log emits one managed-service reconciliation warning instead of retrying continuously.
An on-demand Code Mode path uses the app-bundled cua_node runtime. A task can import @oai/sky through node_repl, which launches the bundled Codex Computer Use.app / SkyComputerUseService independently of the blocked downloaded runtime.

During an active Computer Use task on the second path:

Exactly one SkyComputerUseService remained running for more than 14 minutes.
Five samples over 10 seconds showed no helper-count growth.
The helper had 13 threads and used approximately 240 MB.
launchservicesd had 10 threads and WindowServer had approximately 30, far below the previous 512-thread exhaustion condition.
The Codex app-server had 55 threads and a current physical footprint of approximately 940 MB. This is not the previous approximately 340-thread / OOM signature.
No new app crash, WindowServer watchdog report, kernel panic, or reboot occurred during this observation.

One separate lifecycle concern remains: 22 node_repl broker processes were present. Their count stayed constant during the short sample and each used roughly 19 MB, so this was not an immediate spawn storm, but the count is high relative to four active tasks and may indicate long-session cleanup/retention issues.

So the current local mitigation should be described more precisely as blocking the desktop-managed automatic service path, not disabling every Computer Use implementation. The on-demand bundled path currently works and appears stable in this short observation. This does not prove the original lifecycle race is fixed; removing the managed-runtime block has not been retested because the prior attempts caused kernel panics.

Additional evidence clarifies why the app-bundled on-demand path behaves differently from the desktop-managed path.

The helper binaries are identical

The app-bundled helper and the backed-up downloaded helper have:

The same version: 26.812.1000717 (1000717)
The same SHA-256
The same code-signing CDHash and Team ID
The same bundle identifier: com.openai.sky.CUAService

This makes a helper binary or protocol-version mismatch unlikely. The important difference is service ownership and startup coordination.

The on-demand client has connect-first and single-client behavior

The app-bundled @oai/sky package is version 0.6.11. Its Code Mode implementation:

Caches one client import/promise per node_repl session.
Reuses one transport per API version.
Tries the existing native-pipe socket first with a 250 ms probe.
Requests ensureService only after the socket is unavailable.
After that one ensure request, retries the socket connection for up to 5 seconds at approximately 100 ms intervals instead of launching another helper for every failed probe.

This is consistent with the observed single stable helper during an active Code Mode Computer Use task.

By contrast, the desktop-managed startup path entered ensureServicePidForEnabledFeatures during feature reconciliation and created another GUI helper approximately every 149 ms before the previous instance had become ready. The evidence still suggests this path lacks an effective process-global single-flight/readiness guard or equivalent deduplication.

Quarantine differs, but is probably an amplifier rather than the root cause

The downloaded helper executable had a com.apple.quarantine attribute; the identical app-bundled executable did not. Repeated Gatekeeper/TCC/static-code evaluation of the quarantined copy could increase startup latency and make the race easier to trigger. However, manually removing quarantine would only change timing and would not fix unbounded duplicate launches, so I do not consider it a safe resolution.

The package also contains both the older MCP launcher through $CODEX_HOME/computer-use and the newer Skill instructions that require node_repl + @oai/sky. This looks like a compatibility/migration overlap in the current build, although that interpretation is an inference from the installed package rather than a documented architecture statement.

Additional local containment

I have now removed the turn-ended notification hook so completed turns do not wake the Computer Use client unnecessarily. This does not explain or fix the original app-launch storm, but it removes a separate background lifecycle trigger associated with other reports.

A local watchdog now observes the exact helper process count. It allows the normal single helper, but if three or more helpers persist across two consecutive samples it terminates the desktop app and helper processes and reasserts the blocked managed-runtime directory before the count can approach LaunchServices exhaustion. This is only host protection, not a product fix.

The product-side fix should make the desktop-managed path use the same connect-first/single-flight behavior, enforce one active or starting service globally, wait for readiness with bounded backoff, and provide separate supported controls for background/Appshots service management versus on-demand Computer Use.

I can confirm that I’m experiencing the same regression.

System:

Mac: Mac with M5 Max
Memory: 48 GB
Storage: 2 TB
macOS: 26.5.2

Last known working version:

26.803.81509 — works normally and remains stable

Affected versions I tested:

26.810.41047 — crashes
26.810.50856 — crashes
26.810.52044 — crashes

I can reproduce the issue consistently with every 26.810.x build I’ve tested.

Activity Monitor observations

With the working 26.803.81509 build:

~65 threads
~700 MB RAM
Normal CPU usage
Thread count and memory usage remain stable

With the affected 26.810.x builds:

Thread count starts increasing continuously after launching the app
It eventually reaches 350+ threads and keeps growing
Memory usage also continuously increases, reaching approximately 6 GB
CPU usage becomes very high
The app eventually crashes

The important difference is that the thread count and memory usage never stabilize on the affected builds. They keep increasing until the application crashes.

Downgrading to 26.803.81509 immediately restores the normal behavior (~65 threads / ~700 MB RAM) on the exact same machine.

This strongly suggests a thread/worker and memory leak introduced somewhere between 26.803.81509 and 26.810.41047.

The automatic updater also makes the workaround difficult: after reinstalling the working 26.803.81509 version, a newer affected version is automatically installed after restarting the application.

This issue has made the desktop app unusable for me for several days.

I can provide crash reports, logs, Activity Monitor screenshots, or additional diagnostics if that would help.

I independently reproduced this on the updated build.

Environment:

macOS 26.5 (25F71), Apple Silicon
ChatGPT desktop 26.810.52044 (build 6662)
Bundled Computer Use runtime 26.812.1000717

Controlled A/B test:

With computer_use=false and the managed Computer Use directory blocked/read-only: after relaunch, ChatGPT stayed at 1 process and SkyComputerUseService stayed at 0 for 15 seconds.
To test the updated managed-service path, I temporarily restored the directory and enabled computer_use. On a clean launch, the helper count was:
- t=3s: 1
- t=4s: 5
- t=5s: 10
  The test was aborted at 10 helpers and the processes were stopped immediately.
Earlier runs reached 303 helpers and produced computer-use / V8 node::OOMErrorHandler crashes (including parse_distilled_html frames).
Clearing state and reinstalling/replacing the helper did not change the behavior.

The mitigation is restored: computer_use=false, the managed runtime directory is read-only/quarantined, and the Desktop app relaunches stably with zero Computer Use helpers.

This confirms the spawn storm still reproduces on 26.810.52044; it is not limited to an old stale helper copy.

I can confirm that this issue is caused by the SkyComputerUseService spawn storm on my machine as well, and I can also confirm that blocking the Computer Use runtime directory completely fixes the problem for me.

System

Mac: M5 Max
Memory: 48 GB
Storage: 2 TB
macOS: 26.5.2

Versions tested

Last known working version:

26.803.81509 — works normally and remains stable

Affected versions without the workaround:

26.810.41047 — affected
26.810.50856 — affected
26.810.52044 — affected

Every 26.810.x build I tested exhibited the same behavior before applying the workaround.

Activity Monitor comparison

With the working 26.803.81509 build:

~65 threads
~700 MB RAM
Normal CPU usage
Memory and thread count remain stable
Codex remains stable

With the affected 26.810.x builds:

Thread count continuously increases after startup
It eventually reaches 350+ threads and keeps growing
Memory usage continuously increases to approximately 6 GB
CPU usage becomes very high
Codex eventually crashes

The thread count and memory usage never stabilize on the affected builds.

SkyComputerUseService spawn storm

I compared the running processes between the working and affected versions using:

ps aux | grep -i SkyComputerUseService | grep -v grep

On 26.803.81509, this normally shows only one SkyComputerUseService process:

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

On the affected 26.810.x builds, the same command shows dozens of SkyComputerUseService instances being continuously spawned. Some of the newly spawned processes immediately consume significant CPU.

This continues until CPU, memory and thread usage become excessive and the application eventually crashes.

Important: Computer Use was never enabled

Computer Use is completely disabled/unchecked in my Codex settings.

I have never enabled or used Computer Use.

Despite this, the affected 26.810.x builds continuously spawn SkyComputerUseService processes in the background.

Workaround confirmed

With Codex completely closed, I ran:

mv ~/.codex/computer-use ~/.codex/computer-use.disabled
mkdir ~/.codex/computer-use
chmod 000 ~/.codex/computer-use

After doing this, I launched 26.810.41047 again.

The problem was completely gone:

No more SkyComputerUseService spawn storm
CPU usage remained normal
Memory usage remained normal
Thread count remained normal
Codex no longer crashed
The application became usable normally again

Workaround survives the update to 26.810.52044

I then allowed Codex to update from 26.810.41047 to the latest version currently available to me, 26.810.52044.

After the update, 26.810.52044 also started normally and remains stable with the workaround in place.

The update did not undo the blocked ~/.codex/computer-use directory, and I am no longer seeing the runaway SkyComputerUseService processes, excessive CPU/RAM usage, or startup crash.

So on my machine the A/B result is very clear:

26.810.x without workaround
→ runaway SkyComputerUseService spawning
→ CPU/RAM/thread growth
→ crash

26.810.x with ~/.codex/computer-use blocked
→ normal CPU/RAM/thread usage
→ no spawn storm
→ no crash

I have now confirmed this on 26.810.52044 after updating from 26.810.41047.

Downgrading to 26.803.81509 also immediately restores normal behavior without the workaround, which suggests the regression was introduced somewhere between 26.803.81509 and 26.810.41047.

Hopefully this additional confirmation and the exact workaround help narrow down the regression.

Independent confirmation with a distinct failure signature: the failed helpers are left as real macOS zombie processes, and the helper crash is in AppKit/IOSurface startup rather than V8 OOM.

Environment

ChatGPT desktop: 26.810.52044 (build 6662)
Bundled Codex CLI: 0.148.0-alpha.9
Computer Use helper: 26.812.1000717
Platform: Darwin 25.6.0 arm64 arm
macOS: 26.6.2 (25G82), Apple Silicon

Reproduction and process evidence

Start ChatGPT desktop normally and do not invoke Computer Use.
The configured Computer Use MCP and bundled plugin are both disabled.
The desktop worker nevertheless calls the managed-service path for statusItemMenuState.
During a roughly two-minute startup burst, SkyComputerUseService is launched and exits repeatedly.
After the burst, ps reports 263 direct children of the ChatGPT main process in Z / <defunct> state:

zombies=263 zombie_rss_kb=0 names=SkyComputerUseSe:263

All 263 have the same ChatGPT parent. The ChatGPT parent cwd is /, so this is not tied to a project or worktree. The same pattern occurred under a previous ChatGPT parent process; fully quitting removes the zombies, but relaunching creates a fresh population.

The desktop app log records:

[computer-use-worker] Computer Use service-control worker request failed
errorMessage="Failed to spawn managed Computer Use service"
method=statusItemMenuState

Helper crash signature

A retained SkyComputerUseService crash report shows:

EXC_CRASH / SIGABRT / Abort trap 6
parentProc: ChatGPT

__assert_rtn
___ioSurfaceConnectInternal_block_invoke.cold.1
_ioSurfaceConnectInternal
IOSurfaceClientGetPropertyMaximum
__NSWindowResolvedScaleFactor_block_invoke
NSWindowResolvedScaleFactor
-[NSWindow _commonInitFrame:styleMask:backing:defer:]

The service therefore aborts while initializing NSWindow / IOSurface. Subsequent AppleEvent failures include AESendMessage failed with -600, consistent with the target process already having exited.

This exposes two independently actionable failures:

SkyComputerUseService build 26.812.1000717 can abort during AppKit/IOSurface initialization on macOS 26.6.2.
The desktop supervisor retries the failed helper without reaping it, leaving one zombie per failed launch. A bounded retry alone would limit the storm, but every spawned child must also be awaited/reaped on success, failure, timeout, and cancellation paths.

One additional observation: the downloaded managed helper under $CODEX_HOME/computer-use was changed to mode 000 with the uchg flag immediately after the retry burst. That may be a downstream quarantine/circuit-breaker action rather than the primary cause, because the crash report proves the helper ran and aborted first.

Raw logs and the .ips report remain local because they contain machine paths and identifiers. Sanitized excerpts above are verbatim.

This issue or PR was generated by LazyCodex.
Tag: lazycodex-generated

Adding another independent reproduction with a very similar crash signature.

Environment

MacBook Pro with Apple M1 Pro
Codex app: 26.810.52044
macOS: 27.0

Observed behavior

Codex becomes severely degraded within a few minutes of launch.
Before the latest crash I observed roughly 380 SkyComputerUseService processes.
CPU reached ~100% and system load approached 500.
Roughly 22 GB aggregate memory was being consumed by the helper processes.
macOS entered heavy memory compression/swap and the machine became extremely slow and hot.
Codex then crashed approximately 2.5 minutes after launch.

The crash report showed:

187 Computer Use threads
Dispatch Thread Soft Limit Reached: 64
Node/V8 out-of-memory abort

The 187 Computer Use threads count is particularly notable because it matches the count reported in this issue almost exactly.

This does not look like ordinary high memory usage. From what I can observe, SkyComputerUseService instances continue accumulating until Codex exhausts process/thread/memory resources and aborts.

I’ve reproduced the problem repeatedly on this machine and it currently makes the Codex desktop app effectively unusable.

I can reproduce the same issue on ChatGPT/Codex Desktop 26.814.41407 on macOS.

Environment

ChatGPT/Codex Desktop: 26.814.41407
Platform: macOS / Apple Silicon
Previous Codex configuration: reset/removed before testing

Reproduction

After launching the app, it quickly becomes unresponsive.

I monitored the number of SkyComputerUseService / SkyComputerUseClient processes with:

while true; do
  printf "%s  " "$(date +%H:%M:%S)"
  pgrep -f 'SkyComputerUseService|SkyComputerUseClient' | wc -l
  sleep 1
done

Observed on 26.814.41407:

14:37:20     0
14:37:21     0
14:37:22     0
14:37:23     0
14:37:24     4
14:37:25    12
14:37:26    21
14:37:27    30
14:37:28    38
14:37:29    47
14:37:30    55
14:37:31    63
14:37:32    71
14:37:33    79
14:37:34    87
14:37:35    93

This is approximately 8 new Computer Use processes per second.

Result

The process count continuously increases after startup until the application becomes unresponsive.

I also tested after resetting/removing the previous Codex configuration, but the issue still reproduces. This suggests the problem is not caused by a stale config.toml or configuration migration.

Rollback comparison

I rolled back to 26.730.61639 on the same machine and ran the exact same process monitoring command.

Observed on 26.730.61639:

14:48:23     1
14:48:24     1
14:48:25     1
14:48:26     1
14:48:27     1
14:48:28     1
14:48:29     1
14:48:30     1
14:48:31     1
14:48:32     1
14:48:33     1
14:48:34     1
14:48:35     1
14:48:36     1
14:48:37     1
14:48:39     1
14:48:40     1
14:48:41     1
14:48:42     1
14:48:43     1

The process count remains stable at 1, and the application is usable normally.

This provides a direct A/B comparison on the same machine:

26.814.41407: runaway spawning (~8 processes/sec) → app becomes unresponsive
26.730.61639: stable at 1 process → app works normally

So the SkyComputerUseService spawn storm is still reproducible in 26.814.41407, while rolling back to 26.730.61639 avoids the issue on the same system.

If useful, I can also provide macOS crash logs / process tree information.

Still reproducible on 26.820.60940 (build 7119): full macOS UI freeze

I can confirm that this remains unfixed in the current desktop build, with a newer and more severe reproduction.

Environment

ChatGPT/Codex Desktop: 26.820.60940 (build 7119)
Managed Computer Use helper: 26.819.1000816 (build 1000816)
macOS: 26.5.1 (25F80)
Hardware: Apple Silicon, Mac17,7 / M5 Max, arm64

Impact and forensic evidence

On 2026-08-28 the machine experienced two complete UI freezes, around 01:15 and 01:25 local time, each requiring a forced power-button reset.

The retained WindowServer userspace-watchdog spin from the first incident shows:

launchservicesd: 513 threads, with the report explicitly noting a hard limit of 512.
WindowServer: no successful check-in for 40 seconds.
711 concurrent SkyComputerUseService processes.
The helpers were direct children of the ChatGPT desktop main process and accumulated at approximately 4-5 new processes per second.

The later btn_rst report records the forced reset. It should not be interpreted as the initiating kernel panic; the initiating failure was the userspace WindowServer/LaunchServices deadlock described above.

Hardware checks did not identify an alternative cause: memory had no swap/pageout pressure, SSD SMART/APFS status was healthy, and there were no thermal warnings.

Trigger path in this build

The desktop log repeats:

Failed to load the native Computer Use menu state
errorMessage="Failed to spawn managed Computer Use service"
method=statusItemMenuState

Sampling the ChatGPT parent during the storm shows multiple workers in:

SpawnComputerUseServiceWorker::Execute()
  -> posix_spawn
RemoteHostedPIPContentService sendBootstrap...
  -> AESendMessage

The bootstrap does not complete, the manager does not obtain/save a reusable service PID, and another status-item menu state request starts another helper. There is no effective process-global single-flight guard or retry backoff.

A bounded follow-up test also showed that setting [features] computer_use = false alone is insufficient for the desktop path: after the app refreshed the canonical helper bundle, a second launch produced 38 helpers before it was stopped. This agrees with the log identifying statusItemMenuState, rather than an active Computer Use task, as the trigger.

Verified containment

The following combination survives a cold launch locally:

Disable the menu-bar controller:
defaults write com.openai.codex mac-menu-bar-enabled -bool false
Set [features] computer_use = false, keep the Computer Use MCP disabled, and remove the top-level notify hook that invokes SkyComputerUseClient turn-ended.
Quarantine the canonical helper under $CODEX_HOME/computer-use/.
Set CODEX_ELECTRON_SKIP_COMPUTER_USE_CANONICAL_REFRESH=1 so desktop startup does not silently restore that helper.
Use the real path for CODEX_HOME; on this machine ~/.codex is a symlink, so path canonicalization may be an additional test variable, although it is not proven to be the primary cause.

A controlled cold launch with this containment ran for 20 seconds with:

SkyComputerUseService: 0
canonical managed helper: not recreated
launchservicesd: 5-7 threads
desktop main process CPU: approximately 0.1%

Browser and in-app browser features remained enabled.

Requested product fixes

Make status-item menu state polling honor the supported Computer Use disabled state.
Add a process-global single-flight/readiness guard and a hard maximum of one active or starting helper.
Use bounded exponential backoff and a circuit breaker after bootstrap failures.
Reap failed, timed-out, and superseded child processes.
Do not automatically reinstall or activate a disabled managed helper.
Canonicalize helper paths before validating the spawned executable.

I can provide a redacted WindowServer spin and desktop log excerpts if needed. The raw spin is not attached publicly because it contains a complete local process inventory and filesystem paths.

Follow-up evidence from the same machine after applying the local safety guard:

The Codex/ChatGPT main process has now remained alive for more than 5 hours, with zero SkyComputerUseService helpers and no new crash/panic report. The former 600-second app-termination path remains disabled.
A separate passive resource signal remains: 22 cua_node child processes (11 node_repl / server pairs) currently total about 1.0 GiB RSS. Several have been alive for roughly 5 hours and remain after their subagent work completed. All are children of the Codex app-server.
I have not killed these processes because some may still belong to active agent sessions. The health gate now records count/RSS only and warns above a high bound; it never terminates cua_node or the desktop parent.

This suggests the original self-exit is fixed locally, while long-lived cua_node session cleanup may be a separate accumulation issue worth investigating upstream.

Additional follow-up from the same machine after upgrading to ChatGPT/Codex Desktop 26.820.60940 (build 7119) on macOS 26.5.1:

The desktop parent has remained alive continuously for about 9 hours 42 minutes.
SkyComputerUseService count remains 0, and no new Codex/ChatGPT/Sky diagnostic report has appeared.
The local circuit breaker has been regression-tested at its exact boundary: 20 helpers is accepted, 21 trips cleanup; only helper children are eligible for termination. The desktop parent PID remains unchanged across the test.
All older local automation paths that could terminate ChatGPT/Codex have also been removed or converted to report-only. This separates a local self-exit contributor from the upstream unbounded helper-spawn/freeze failure described here.

This is continued evidence that a bounded helper-only circuit breaker prevents whole-machine failure without requiring the desktop parent to be killed. It does not establish that the upstream helper lifecycle is fixed, because the local guard/disabled helper state remains active.

No longer reproducible on 26.901.51231

I retested this issue today on ChatGPT/Codex Desktop 26.901.51231, released Sep 6, 2026, on the same Apple Silicon Mac where I previously reproduced the runaway SkyComputerUseService spawning.

Importantly, no workaround is active:

launchctl getenv CODEX_HOME

returns no value.

My existing configuration is unchanged:

~/.codex is still a symlink
CODEX_HOME is not overridden
no real-path workaround is being used

I monitored the Computer Use processes with:

while true; do
  printf "%s  " "$(date +%H:%M:%S)"
  pgrep -f 'SkyComputerUseService|SkyComputerUseClient' | wc -l
  sleep 1
done

Observed on 26.901.51231:

13:04:06  0
13:04:07  0
13:04:08  0
13:04:09  0
13:04:10  0
13:04:11  0
13:04:12  0
13:04:13  0
13:04:14  0
13:04:15  1
13:04:16  1
13:04:17  1
...
13:04:43  1

The helper starts normally and remains stable at exactly 1.

For comparison, on this same machine:

26.814.41407: runaway spawning at approximately 8 processes/sec → app became unresponsive
26.730.61639: stable at 1 process
26.901.51231: stable at 1 process with the original symlink-based configuration and no CODEX_HOME workaround

So the original SkyComputerUseService spawn storm is no longer reproducible in my environment on 26.901.51231.

This is the first current build I have tested that appears to resolve the issue without requiring any change to my existing Codex configuration layout.

Update (2026-09-09): OpenAI fixed this in Codex 26.901.51231. Installed it from the official DMG (https://persistent.oaistatic.com/codex-app-prod/Codex.dmg) on the same machine: 1 helper process, 0 not authenticated errors, Computer Use working. If you are stuck on 26.8xx it is probably because the swarm starves the app before its own update check (~54 min after launch) runs, so it never updates itself. Download the DMG and replace the app, or codex-guard update does it with a signature check and a backup. The lock below is now only the fallback for people who cannot update.

Still reproducible on Codex 26.820.60940 / macOS 26.6.2 (M5, 16 GB). It took my machine from 1,503 processes and 5 GB swap to a WindowServer watchdog kernel panic (no successful checkins from WindowServer (2 induced crashes) in 3913 seconds).

Root cause on my box, from running the app with --enable-logging:

[computer-use-worker] Computer Use service-control worker request failed
errorMessage="Codex Computer Use Apple Event error -10000: Sender process is not authenticated"

The bundled helper (~/.codex/computer-use/Codex Computer Use.app, 26.819.1000816, Sparkle feed on the alpha channel now returns 403) rejects the 26.820 app, so onServiceConnectionLost fires, Codex spawns another helper, and every copy stays alive. ~8/sec for two minutes, 978 processes.

Things that do not stop it (each tested by relaunching and counting pgrep -f SkyComputerUseService for 2 minutes): plugins."computer-use@openai-bundled".enabled = false, [mcp_servers.computer-use] enabled = false, removing the notify hook, remote_control_enabled = false, computer-use-bundled-plugin-auto-install-disabled = true in global state, clearing the IPC socket lock in the group container, and deleting the helper bundle (Codex reinstalls it within seconds).

What does stop it: make the helper binary non-executable and immutable, so Codex can neither run nor replace it.

B="$HOME/.codex/computer-use/Codex Computer Use.app/Contents/MacOS/SkyComputerUseService"
pkill -9 -f SkyComputerUseService
chmod 000 "$B" && chflags uchg "$B"

Result: 0 helpers after relaunch, Codex idle at ~2% CPU, load average 2.5. Computer Use is off until OpenAI ships a helper that accepts the app; chflags nouchg + chmod 755 restores it.

Because Codex replaces the bundle on every update, I wrapped this in a script with a 60-second re-lock LaunchAgent and diagnose / install / unlock commands: https://github.com/celesticlabs/codex-guard (MIT, 160 lines, no sudo, no network). Hope it saves someone a panic.

Navigation Menu

Repository navigation

[Bug] Computer Use spawn storm exhausts launchservicesd and triggers WindowServer watchdog kernel panic on macOS 26.5 #38760

Summary

Environment

Timeline and observed impact

Desktop app crash signature

Managed service failure

AppleEvent failure

Kernel panic / system evidence

Reproduction

Mitigations tested

Requested fixes

Related issues

The helper binaries are identical

The on-demand client has connect-first and single-client behavior

Quarantine differs, but is probably an amplifier rather than the root cause

Additional local containment

Environment

Reproduction and process evidence

Helper crash signature

Environment

Reproduction

Result

Rollback comparison

Still reproducible on 26.820.60940 (build 7119): full macOS UI freeze

Environment

Impact and forensic evidence

Trigger path in this build

Verified containment

Requested product fixes

No longer reproducible on 26.901.51231

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[Bug] Computer Use spawn storm exhausts launchservicesd and triggers WindowServer watchdog kernel panic on macOS 26.5 #38760

Description

Summary

Environment

Timeline and observed impact

Desktop app crash signature

Managed service failure

AppleEvent failure

Kernel panic / system evidence

Reproduction

Mitigations tested

Requested fixes

Related issues

Activity

github-actions commented on Aug 15, 2026

jo910904 commented on Aug 15, 2026

jo910904 commented on Aug 15, 2026

The helper binaries are identical

The on-demand client has connect-first and single-client behavior

Quarantine differs, but is probably an amplifier rather than the root cause

Additional local containment

MarcusElmett commented on Aug 16, 2026

osamu2001 commented on Aug 16, 2026

MarcusElmett commented on Aug 16, 2026

nolainjin commented on Aug 16, 2026

Environment

Reproduction and process evidence

Helper crash signature

kalanidhik commented on Aug 17, 2026

Billin9 commented on Aug 19, 2026

Environment

Reproduction

Result

Rollback comparison

LeoLin990405 commented on Aug 27, 2026

Still reproducible on 26.820.60940 (build 7119): full macOS UI freeze

Environment

Impact and forensic evidence

Trigger path in this build

Verified containment

Requested product fixes

LeoLin990405 commented on Aug 27, 2026

LeoLin990405 commented on Aug 28, 2026

Billin9 commented on Sep 6, 2026

No longer reproducible on 26.901.51231

celesticlabs commented on Sep 8, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions