[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:

1. The desktop app accumulated roughly 340 threads and crashed from a V8/Node OOM after about 60-80 seconds.
2. 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:

1. Allow the normal Computer Use runtime to exist under the Codex home directory.
2. Launch the ChatGPT desktop app / Codex.
3. Do not invoke Computer Use; simply observe processes after launch.
4. Within approximately five seconds, multiple SkyComputerUseService processes begin spawning.
5. 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:

1. Add a process-global single-flight/in-progress guard around managed Computer Use service startup.
2. Enforce a hard maximum of one active/starting service instance.
3. Add bounded retry with exponential backoff and a circuit breaker; never retry several times per second.
4. Cancel and reap failed/superseded helpers and pending AppleEvent requests.
5. Move slow security/privacy initialization off the helper's main thread where possible.
6. Ensure the desktop app honors a supported Computer Use disabled state without automatically reinstalling or re-enabling it.
7. Add a regression test that simulates slow helper startup and verifies no second instance is launched.
8. 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

• #25744 - Computer Use / MCP helper accumulation and WindowServer/TCC stalls
• #20683 - -609 connectionInvalid from Computer Use
• #37420 - Computer Use/replayd reconnect loop
• #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.

Start at the desktop log entry point ensureServicePidForEnabledFeatures and trace managed Computer Use service startup and reconciliation. Review related issues #25744, #20683, #37420, and #29157, then identify the existing service and AppleEvent lifecycle tests. Done means slow or failed startup cannot launch concurrent helpers or retry indefinitely, with a regression test covering the single-flight behavior.