[macOS] Computer Use leaks ~190 workers blocked in AESendMessage → V8 OOM abort ~90s after every launch (26.810.x)

What version of the Codex App are you using (From "About Codex" dialog)?

26.810.52044 (build 6662) — also reproduces identically on 26.810.41047 (build 6570)

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.6.0 arm64 arm — macOS 26.6.1 (25G76), Apple M3 Max, 36 GB RAM

What issue are you seeing?

On 26.810.x the desktop app kills itself 80–90 seconds after every launch, with no user interaction — I never opened or used Computer Use. Rolling back to 26.803.81509 makes it completely stable.

Crash signature, identical across 7 crashes (~/Library/Logs/DiagnosticReports/ChatGPT-*.ips):

exception:  EXC_CRASH (SIGABRT) — Abort trap: 6
Triggered thread: V8Worker
    abort
    node::OOMErrorHandler(char const*, v8::OOMDetails const&)
    ...
Thread inventory (324–328 total):
    187 x "computer-use"
     70 x com.apple.root.user-initiated-qos   <- equals the Dispatch Thread Soft Limit

About 150 of those computer-use threads are parked in the exact same stack — a synchronous AppleEvent send that never returns:

__ulock_wait
_dispatch_group_wait_slow
AE                    AESendMessage
node.napi.armv8.node  ffi_call_SYSV
sky.node              Napi::details::CallbackData<...>::Wrapper

Growth measured by polling ps -M / RSS on the main process (same curve on both 26.810 builds):

| t+7s | t+22s | t+37s | t+52s | t+67s | t+82s |
|---|---|---|---|---|---|
| 65 thr / 594 MB | 147 / 918 MB | 202 / 2.4 GB | 254 / 4.0 GB | 303 / 2.9 GB | crash |

System memory is not the constraint (36 GB, 84% free, zero swap) — this is a V8 OOM caused purely by the number of leaked isolates.

Launching with AEDebugSends=1 shows the loop:

{SkCu,PiPB target='kpid'[pid=19733 {ClVn=utxt("CodexComputerUse")} returnID=...}
{SkCu,SndR target='kpid'[pid=19737 ...
{SkCu,PiPB target='kpid'[pid=19741 ...

709 AppleEvents in ~45 s, and the target pid increments by 4 every time — the app is respawning SkyComputerUseService roughly 3x/second and firing 6 events at each new instance. ps sampling confirms ~150 concurrent SkyComputerUseService processes at peak. Every send blocks forever, and each blocked send pins one node worker plus its V8 isolate.

One more possibly relevant detail: the bundled CUA helper is on a different version line than the app — ~/.codex/computer-use/Codex Computer Use.app reports com.openai.sky.CUAService 26.812.1000717 while the app itself is 26.810.52044.

What steps can reproduce the bug?

1. macOS 26.6.1 on Apple Silicon, Codex desktop 26.810.41047 or 26.810.52044.
2. Launch the app. Don't touch Computer Use.
3. Watch thread count and RSS on the main process (ps -M), or just wait.
4. ~80–90 s later the process aborts.

Reproduced 7/7 (5 spontaneous, 3 deliberate).

Things that do NOT stop it, in case it narrows things down:

• Deleting the leftover session file in ~/.codex/computer-use/sessions/*.toml
• Setting enabled = false for computer-use@openai-bundled in config.toml
• Setting computer-use-bundled-plugin-auto-install-disabled = true in global state — this does stop SkyComputerUseService from spawning (0 processes for the whole run), but the thread/memory growth and the crash continue, and actually get faster (4 GB by t+12s)
• Removing ~/.codex/computer-use entirely (the app re-provisions it and behaves the same)
• tccutil reset AppleEvents com.openai.codex

That third one looks like the useful clue: suppressing the helper process does not suppress the leak, so the unbounded worker creation appears to be on the app side (sky.node / its JS caller) rather than a downstream effect of helper spawn failures.

What is the expected behavior?

Worker/helper creation should be bounded and backed off, and the AppleEvent send should have a timeout. A Computer Use handshake that can't complete should degrade that one feature, not accumulate ~190 blocked workers and OOM-abort the entire app.

Additional information

• 26.803.81509 (build 6415) is unaffected — 1298 minutes (21.6 h) of continuous uptime, flat at ~580 MB / 62 threads. Both 26.810.41047 and 26.810.52044 fail identically, so this has survived at least one release.
• Worth flagging for anyone who rolls back: Sparkle auto-update replaced my working 26.803 install with 26.810.52044 overnight, and SUEnableAutomaticChecks / SUAutomaticallyUpdate are rewritten back to 1 by the app on every launch, so a rollback doesn't stay rolled back. Setting SUScheduledCheckInterval to a large value is the only preference that survived a relaunch for me.
• Possibly the same underlying 26.810.x Computer Use regression as #38508 (macOS Computer Use failing with noWindowsAvailable (-10005)), although the symptom there is a non-crashing failure.