›_ Codex Issues
Codex Issues / #38760

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

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

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.

View original on GitHub ↗

12 Comments

github-actions[bot] contributor · 12 days ago

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

  • #38697
  • #38455
  • #38720
  • #38515
  • #38744

Powered by Codex Action

jo910904 · 12 days ago

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:

  1. 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.
  2. 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.

jo910904 · 12 days ago

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:

  1. Caches one client import/promise per node_repl session.
  2. Reuses one transport per API version.
  3. Tries the existing native-pipe socket first with a 250 ms probe.
  4. Requests ensureService only after the socket is unavailable.
  5. 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.

MarcusElmett · 12 days ago

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.

osamu2001 · 12 days ago

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.

MarcusElmett · 12 days ago

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.

nolainjin · 11 days ago

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

  1. Start ChatGPT desktop normally and do not invoke Computer Use.
  2. The configured Computer Use MCP and bundled plugin are both disabled.
  3. The desktop worker nevertheless calls the managed-service path for statusItemMenuState.
  4. During a roughly two-minute startup burst, SkyComputerUseService is launched and exits repeatedly.
  5. 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:

  1. SkyComputerUseService build 26.812.1000717 can abort during AppKit/IOSurface initialization on macOS 26.6.2.
  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

kalanidhik · 11 days ago

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.

Billin9 · 9 days ago

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.

LeoLin990405 · 17 hours ago

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:

  1. Disable the menu-bar controller:

defaults write com.openai.codex mac-menu-bar-enabled -bool false

  1. Set [features] computer_use = false, keep the Computer Use MCP disabled, and remove the top-level notify hook that invokes SkyComputerUseClient turn-ended.
  2. Quarantine the canonical helper under $CODEX_HOME/computer-use/.
  3. Set CODEX_ELECTRON_SKIP_COMPUTER_USE_CANONICAL_REFRESH=1 so desktop startup does not silently restore that helper.
  4. 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.

LeoLin990405 · 12 hours ago

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.

LeoLin990405 · 7 hours ago

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.