ChatGPT desktop 26.810.41047 repeatedly spawns Computer Use workers and crashes with V8 OOM on macOS

macOS 15.7.7, Apple Silicon, 32 GB RAM
App version 26.810.41047, build 6570
Previous version 26.730.61639 worked
Reproduces while idle, 98 seconds after launch
SIGABRT through node::OOMErrorHandler
316 threads at crash; 187 named computer-use
Telemetry showed 78 unexplained child processes consuming about 4.96 GB after 29 seconds
Browser and Computer Use flags were explicitly disabled
App restored the SkyComputerUseClient notifier at startup
Crash incident ID: 096C41F9-EE0C-4136-BEDF-9035077248B7
CLI remains healthy; all databases pass integrity/parity checks

ChatGPT-26.810.41047-crash.zip

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

ChatGPT/Codex macOS app continuously leaks zombie subprocesses while idle #37311
macOS desktop app ≥26.730 crash-loops on launch on 16 GB Apple Silicon Mac (V8 crash ~6–15 s after launch); same builds fine on 48 GB machine #37493

I can reproduce a related macOS desktop failure, but without the Computer Use worker pattern described above.

Environment:

ChatGPT/Codex desktop 26.803.61601 (build 6396), Chromium 151.0.7922.76
macOS 26.6.1 (25G76)

On 2026-08-13 I recorded five Apple crash incidents: 5FC1B088-AD38-45A8-B80A-5FC8F9E89B7C, 3B49E19E-C8C9-484C-852B-7D84FF7133CA, 83F8B3B6-5455-4E49-8DC0-6A8A3CE026E5, 05F2AEF5-2C4A-4BAB-AEC4-391953648B08, and 8160CEFB-07DB-4D77-858E-922C9254DC11.

All show EXC_BREAKPOINT / SIGTRAP in V8/Chromium; observed V8 frames include v8::Extension and v8::ExternalMemoryAccounter::Decrease. Earlier desktop logs also contained V8 heap/OOM markers.

The crashes correlate with rehydrating or switching very large Codex task histories. Archiving three completed unpinned transcripts reduced active session storage by 1.18 GiB (to 4.96 GiB), but did not eliminate the same V8 crash signature. A fresh app process was only about 422 MiB RSS, so this does not appear to be system-wide RAM exhaustion.

Please also investigate task-history rehydration and V8 external-memory handling on macOS. I can provide the Apple .ips reports privately if useful; I am intentionally not attaching raw diagnostics here.

Additional local evidence after mitigation:

Manually archived the 1,851,727,567-byte oversized task. Nonarchived session storage fell from 4.958 GiB to 3.078 GiB.
Found 39 orphaned ChatGPT/Codex helpers from prior app launches, all with PPID 1: 26 Crashpad handlers and 13 bare-modifier monitors. After exact per-PID validation, TERM removed all 39 and released 544,064 KiB RSS.
The current app process and its helpers were protected. Despite that cleanup, within about 6.5 minutes the current renderer reached 1,702,400 KiB RSS and the Codex app-server reached 1,398,752 KiB RSS (about 2.96 GiB combined).
The app bundle passes deep/strict code-signing verification and Gatekeeper notarization checks; core Codex SQLite stores return PRAGMA quick_check=ok.

This now points to two linked product-side defects rather than local app corruption: orphan-helper cleanup after renderer/app crashes, and unbounded renderer/app-server growth during task catalog/session-history rehydration. Archiving reduces the trigger surface but does not fix the live-process leak.

This is a serious problem!

I can reproduce what appears to be the same issue on the exact same app build.

Environment:

ChatGPT desktop 26.810.41047 (build 6570)
Apple Silicon
macOS 26.5.2

The app crashes consistently around 1–2 minutes after launch, even while idle.

I sampled the ChatGPT process every ~10 seconds and observed the number of computer-use threads continuously increasing:

14:16:17 5
14:16:30 28
14:16:45 54
14:17:00 79
14:17:13 91
14:17:25 121
14:17:38 149
14:17:51 177
→ crash

The Apple crash report is also extremely similar:

EXC_CRASH / SIGABRT
node::OOMErrorHandler → abort()
316 total threads at crash
~186 threads named computer-use

Most of the computer-use threads in my crash report are blocked around:

AESendMessage
→ objc-js
→ sky.node

I also completely removed and reinstalled the app and deleted ~/.codex, but the issue reproduces.

After each crash, bare-modifier-monitor is left orphaned with PPID 1, although SkyComputerUseService itself exits with the main app.

This looks like the same Computer Use thread/resource leak described in this issue.

I can reproduce the same issue on ChatGPT Desktop 26.810.41047 (Build 6570), macOS 26.6.1, Apple Silicon.
The app continuously spawns dozens of ChatGPT Computer Use processes, even when Full Access and Computer Control permissions are disabled.
My crash report also shows EXC_CRASH / SIGABRT, node::OOMErrorHandler, and sky.node. Reinstalling the app and clearing Codex caches did not resolve it

Corroborating this exact failure on the same desktop build.

Environment:

ChatGPT/Codex Desktop 26.810.41047 (build 6570)
bundled Codex 0.148.0-alpha.9
Computer Use plugin/runtime 1.0.1000717
Darwin 25.6.0 arm64 arm

Clean reproduction and measurements:

A separate temporary local launchd self-repair job had initially caused an unrelated 15-second relaunch loop. It was completely unloaded before the clean reproduction below, so the OOM failure is independent of that job.
With Computer Use enabled, matching Computer Use worker activity grew to 144 at 26 seconds, 198 at 36 seconds, and 437 at 76 seconds after launch; 439 unique worker instances appeared in the captured log.
The app aborted at roughly 90 seconds. Five macOS crash reports showed SIGABRT through node::OOMErrorHandler, with the failing V8 worker identified as computer-use.
Resetting the Computer Use cache/runtime did not prevent recurrence.
Setting [features] computer_use = false and restarting left the app stable for more than 8 minutes with a single helper, roughly 530 MB RSS, low CPU, and no new crash report.

Uploaded diagnostic thread: 019fff85-84db-7621-8f00-941ea44f2e01

This strongly matches the Computer Use worker/resource leak reported here, rather than general system memory pressure or database corruption.

Another exact reproduction from an affected user (sanitized and posted on their behalf).

Environment

ChatGPT Desktop: 26.810.41047 (Build 6570)
macOS: 26.6.1 (25G76)
Apple Silicon, hardware model Mac17,9, 24 GB RAM
Regression began immediately after updating the desktop app; the previous version was working normally the night before.

Reproduction / mitigations already tried

Reproduces while the app is idle, roughly 60–70 seconds after launch.
A full Mac reboot did not help.
Disabling the Computer Use skill/server did not help.
Uninstalling the Computer Use plugin did not help.

Latest macOS hang report

Incident ID: 6B809A63-113A-4D68-9893-4C6E47346048

Event: hang
App became unresponsive 7 seconds before sampling.
148 ChatGPT threads.
Dispatch Thread Soft Limit Reached: 75 (too many dispatch threads blocked in synchronous operations).
ChatGPT footprint was only about 502.61 MB, so the thread/process leak appears to precede the later OOM crash.
The same stackshot contains 90 distinct SkyComputerUseService process entries/PIDs from a single ChatGPT launch.
Each service reports Parent: ChatGPT and Responsible: ChatGPT.
Service path: /Users/<redacted>/Codex Computer Use.app/Contents/MacOS/SkyComputerUseService
Service version: 26.812.1000717 (1000717), while the host app is 26.810.41047 (6570).
Repeated blocked path across dispatch threads:

RemoteHostedPIPContentService sendBootstrapToServiceWithProcessIdentifier
→ NSAppleEventDescriptor sendEventWithOptions
→ AESendMessage
→ _dispatch_group_wait_slow
→ __ulock_wait

computer-use Node worker threads are still present even after the plugin was disabled and uninstalled, with calls through sky.node / node.napi.armv8.node into AESendMessage.

Earlier crash report

Incident ID: 1C13B090-A2DB-4BF9-80F0-B1EF69E7208D

EXC_CRASH (SIGABRT) / Abort trap: 6
Dispatch Thread Soft Limit Reached: 75
Crashed V8 worker ends in node::OOMErrorHandler(...) → abort().

This looks like a host-side retry/spawn loop in the bundled Computer Use runtime, rather than a user plugin configuration problem: the desktop app continues to initialize and repeatedly spawn the Computer Use helper after the visible plugin has been disabled and removed.

Please consider shipping an urgent hotfix and, if possible, a true startup kill switch that prevents the bundled Computer Use runtime/helper from loading. Full .ips / stackshot reports are available privately if an OpenAI maintainer needs them.

Same build here (26.810.41047, build 6570) on macOS 26.5.2 (25F84), Apple M4, 24 GB. I filed #38589 separately before finding this thread and am closing it as a duplicate — moving the evidence here, since I have two things this thread does not yet have: a stack showing the spawns are synchronous, and a clean before/after comparison across the update.

My machine does not reach the V8 OOM crash — it freezes instead. The UI stops responding and, critically, system-wide mouse and keyboard input goes with it. That difference is explained by the stack below.

1. The spawns are `spawnSync` on the Electron main thread

sample of the main process (pid 80696, 12 s, 8814 samples/thread) resolves the spawn path to Node's synchronous process runner:

node::SyncProcessRunner::Spawn(v8::FunctionCallbackInfo<v8::Value> const&)  (in Codex Framework) + 640
uv_spawn  (in Codex Framework) + 2732
posix_spawn  (in libsystem_kernel.dylib) + 496
__posix_spawn  (in libsystem_kernel.dylib) + 0

SyncProcessRunner is child_process.spawnSync. At ~5 spawns/sec on the main thread, the event loop is blocked essentially continuously — which is why the freeze extends past the app to the whole desktop, rather than just producing a slow UI.

Supporting hotspots in the same sample: heavy v8::ArrayBuffer::New churn plus node::IsolateData::CreateIsolateData and node::worker::MessagePort::New, consistent with each spawn rebuilding worker state. That churn is likely the same pressure that ends in OOM on the 32 GB machine in the original report.

2. Measured churn — 75 unique children in 14 seconds

Sampling every ChatGPT-family process every 2 s starting right after launch:

t after launch	live `Contents/Resources/codex` children
+14 s	19
+16 s	27
+18 s	21
+20 s	13
+22 s	2
+24 s	11
+26 s	16
+28 s	20

The PIDs are entirely different at each snapshot — these are not long-lived workers:

75 unique PIDs in that 14-second window
PID space advanced 80731 → 81455 (724 PIDs consumed)
≈ 5 spawns/sec, sustained
Each child holds 40–120 MB RSS; main-process physical footprint peaked at 597 MB

This lines up with the "78 unexplained child processes after 29 seconds" in the original report, and with the zombie accumulation in #37311 — I think all three are the same respawn loop observed at different points.

Menu-bar CPU hit 99.9% about 15 s after launch, and launchd itself showed 42.5% — a process whose only job here is spawning and reaping, which is a fairly direct fingerprint of the loop.

3. Before/after the update, same machine, same day

~/Library/Logs/com.openai.codex/:

session	version	uptime	`[IpcRouter] I am the router`	log files written
pid 93935	pre-update	10 h 56 min	0	2
pid 83373	26.810.41047	2 min	158	65
pid 89094	26.810.41047	2 min	171	73
pid 58173	26.810.41047	4 min 30 s	296	127

The three short sessions are short only because I force-quit them. [IpcRouter] I am the router does not appear once in the 2,320-line pre-update log spanning nearly 11 hours; it appears 158–296 times per 2–4 minutes afterwards. The app also opens a new log file per spawn — 2 files per session before, 65–127 after, nearly all zero-byte.

Broadcast storms accompany it, up to 45 log lines in a single second:

warning [IpcClient] Received broadcast but no handler is configured method=client-status-changed

Sessions end with:

warning [IpcRouter] Socket error errorCode=EPIPE errorMessage="write EPIPE"
    at Tse.broadcastClientStatus (…/app.asar/.vite/build/src-BlUt09P1.js:1032:7497)
    at Tse.unregisterClient (…/app.asar/.vite/build/src-BlUt09P1.js:1032:6594)

4. Possible trigger — stale plugin app-server copy (hypothesis)

The update did not refresh the installed plugin app-server. The installed copies are still the ones written by the previous version:

file	size	sha256 (first 16)	mtime
`/Applications/ChatGPT.app/Contents/Resources/codex`	219,666,000	`7a26b07855ef9119`	2026-08-14 17:04
`~/.codex/plugins/.plugin-appserver/codex`	218,437,552	`04ddea2f332bd524`	2026-08-11 17:58
`…/Resources/codex-code-mode-host`	51,495,456	`206000a48fbe9d2f`	2026-08-14 17:04
`~/.codex/plugins/.plugin-appserver/codex-code-mode-host`	49,992,576	`75575bbeae891d4e`	2026-08-11 17:58

Both are hash-mismatched against the bundle, so the file-equivalence check in chrome-plugin-app-server-runtime (the XK sha256 helper identified for Windows in #38547) can never succeed. A reconcile that re-checks and relaunches on every failure would produce exactly this unbounded loop.

Stated as a hypothesis, not a conclusion: on macOS bundled_plugins_reconcile_started only appears 2–3 times per session in my logs, so I have not shown the reconcile path is the caller of the spawnSync loop. The measured facts are the spawn rate, the synchronous stack, and the router storm.

Suggested fix direction

Whatever drives this loop, the app-server launch and any file-equivalence check should be asynchronous so they can never block the Electron main thread, and a failing equivalence check should back off and surface an error instead of retrying without bound. The synchronous call is what turns a background bug into a desktop-wide input freeze.

Happy to attach the raw sample output (10.7 MB) and the per-PID churn log if that is useful.

Correction and follow-up to my comment above — I re-examined the same sample output and one of my claims was overstated. I also now have the caller path, and it points at Computer Use, which supports the original report rather than my plugin-app-server guess.

1. Correction: the main thread is not blocked continuously

I wrote that "the event loop is blocked essentially continuously." That is not what the data shows, and I should not have written it.

Measured on the main thread (Thread_28350855, DispatchQueue_1: com.apple.main-thread), out of 8,814 samples over 12 s:

frame	samples	share of main-thread samples
`node::SyncProcessRunner::Spawn`	139	1.6 %
…of which reach `posix_spawn`	19	0.2 %

So spawnSync on the main thread is real and is a genuine defect, but it accounts for roughly 1.6 % of main-thread time in that window — not continuous blocking. My "which is why the freeze extends past the app to the whole desktop" was wrong as stated.

What I think actually causes the desktop-wide stall: system-level CPU saturation from the child processes themselves, not main-thread blocking. During the freeze, menu-bar CPU read 99.9 %, and launchd — whose work here is spawning and reaping — was itself at 42.5 % of a core, alongside 11–27 live codex children at any instant, each 40–120 MB RSS. The spawn rate is the problem; the synchronous call is an aggravating factor on top of it.

For completeness, the async spawns are on the libuv workers, which is expected: posix_spawn appears there at 2, 7, 12 and 12 samples across four libuv-worker threads. Only the main-thread path goes through SyncProcessRunner.

2. The caller path — Computer Use worker messages

The full main-thread stack into the spawn is:

__CFRunLoopRun
  __CFRUNLOOP_IS_CALLING_OUT_TO_A_SOURCE0_PERFORM_FUNCTION__
    uv_run
      uv__io_poll
        node::worker::MessagePort::OnMessage(...)        ← message from a Node Worker
          node::AsyncWrap::MakeCallback
            node::InternalMakeCallback
              [JIT frames]
                node::SyncProcessRunner::Spawn(...)      ← child_process.spawnSync
                  node::SyncProcessRunner::Run
                    node::SyncProcessRunner::TryInitializeAndRunLoop

MessagePort::OnMessage on the main thread accounts for 55 samples and is the parent of the spawn frames.

The relevant detail: 14 of the Node Worker threads in the main process are named computer-use. Each runs its own node::worker::Worker::Run → SpinEventLoopInternal → uv_run loop and posts back over MessagePort. That matches the original report here (187 computer-use threads at crash time on a 32 GB machine — mine froze before reaching that count).

So the shape is: Computer Use workers post messages → the main-thread handler spawns a child synchronously per message → ~5 spawns/sec of the 219 MB codex binary → 75 unique child PIDs in 14 s, 724 PIDs of churn.

Corroborating log lines from the same sessions:

warning Failed to load the native Computer Use menu state errorMessage="AESendMessage failed with -600" errorName=Error
warning Failed to load the native Computer Use menu state errorMessage="Worker bus disposed for 'computer-use'" errorName=Error

-600 is procNotFound — the Apple Event target is gone. A retry loop around a target that never comes back would produce exactly this message-per-spawn pattern.

Worth noting: Browser and Computer Use were reported as explicitly disabled in the original report, and the app still restored SkyComputerUseClient at startup. On my machine SkyComputerUseClient and Resources/cua_node/bin/node_repl were both running.

3. Retracting my plugin-app-server hypothesis as the likely cause

In my previous comment I floated the stale ~/.codex/plugins/.plugin-appserver/ hash mismatch as a possible trigger. The stale-copy observation stands as a fact — those files are still from the previous version and hash-mismatched — but it is not the caller of this loop, and I no longer think it is the cause. bundled_plugins_reconcile_started appears only 2–3 times per session in my logs, while the spawn loop runs continuously. The Computer Use path above is a much better fit. Treat the stale copy as a separate, lower-priority observation.

Credit where due: the Computer Use attribution in the original report was right, and my alternative was not.

Additional configuration detail that may help reconcile the reported workaround using [features] computer_use = false:

Before relaunch, codex doctor --json confirmed that the computer_use feature override was false; the browser-related feature overrides and the Computer Use MCP entry were also disabled. The desktop app nevertheless crashed with the same ~98-second worker-growth/OOM pattern.

At app startup (19:21:05 local time), the app rewrote ~/.codex/config.toml—the file mtime matched startup—and restored this active hook:

notify = ["/Users/flannick/codex-workspace/codex-home/computer-use/Codex Computer Use.app/Contents/SharedSupport/SkyComputerUseClient.app/Contents/MacOS/SkyComputerUseClient", "turn-ended"]

The startup log recorded an experimentalFeature/enablement/set event at the same time. So computer_use = false may stabilize the app when it remains fully effective, while in my case the desktop app's configuration reconciliation restored the Computer Use client hook. That difference may explain why the workaround succeeds for some users but did not prevent my crash.

Feedback ID: no-active-thread-01a01a29-526c-7080-8192-bbb379e4c1ec

Still reproducible on 26.814.41407 (build 6720) — plus two data points I haven't seen in this thread: the storm is gated on being signed in, and it reproduces on macOS 14 (Sonoma), not just 26.x.

Environment

ChatGPT Desktop: 26.814.41407 (build 6720), bundle id com.openai.codex
Codex Framework: 151.0.7922.137
Computer Use runtime: 26.817.1000761
macOS: 14.6.1 (23G93), Apple Silicon — so the affected OS range is wider than the 26.x reports above

Signature (matches OP)

~20 crashes since the app auto-updated on Aug 18. Every launch: SkyComputerUseService children spawn at ~4/sec from t=0, each pinning a thread named computer-use in the main process; SIGABRT via node::OOMErrorHandler at ~185–450 threads, 2.5–5.5 minutes after launch. No user-initiated computer-use task; this is startup behavior.

Signed-in vs signed-out A/B (controlled, one variable)

Fresh CODEX_HOME (no auth.json, everything else app-default): clean and stable — ~60 threads, 2–3 services, flat.
Identical fresh state + my real auth.json: full spawn storm and OOM crash.

Before finding that, I falsified every local-state candidate one at a time (each: quit, remove/restore one item, relaunch, sample thread + child-process counts every 20–30s): app profile (~/Library/Application Support/Codex), process_manager/chat_processes.json (192 stale entries), session rollouts (503 files — also tested trimmed to 2 days), state_5.sqlite threads table (1,089 rows — also tested at 25 rows), goals_1.sqlite (one blocked goal), config.toml (removed entirely), plugin cache, and the Computer Use runtime bundle (app reinstalls it byte-identical on launch). All storm. Only the signed-out run is clean.

Conclusion: the spawn loop is armed by authenticated account state, not local machine state. Possibly related: my .codex-global-state.json carries electron-remote-hosted-pip-task-visibility-state with two remote hosted task IDs (matches the RemoteHostedPIPContentService bootstrap in #38744's trace).

Containment from #38744 does NOT hold on 26.814

Applied the full combo from #38744's closing comment (remove the notify turn-ended hook, [features] computer_use = false, move the Computer Use runtime dir aside):

The app re-adds the notify hook to config.toml and reinstalls the runtime dir on every launch, computer_use = false notwithstanding.
Spawn rate drops ~4/sec → ~1/sec and the app outlives the usual 2.5-minute death, but the leak continues unbounded (310 threads at 6 minutes, still climbing) and the app still dies.

So on this build the flag only slows the storm; it does not stop it.

Happy to attach .ips crash reports or run diagnostics against a candidate build.

The spawn storm is on the same box as the desktop app, so when Computer Use workers run away they take the Mac (and any overnight job) with them. A computer_use = false flag the desktop ignores is consistent with the workers being launched from the app process, not from a separate host.

Split that actually survives: keep ChatGPT/Codex as the UI, run the long job on a fenced VPS that does not sleep and does not share the desktop process. Approve money / customer / production in the browser so a dead laptop is not the gate.

If you just need that overnight split: hosted Hermes, $10/mo, 14-day trial — https://thumbgate.app

Controlled build 6744 retest with fresh Computer Use helper

I reproduced the same startup spawn storm on the current production macOS release and ran a recoverable helper-reset A/B test.

Environment:

ChatGPT Desktop 26.814.41957 (build 6744)
Apple Silicon (arm64)

First launch with the pre-existing helper:

45 live SkyComputerUseService processes by about 23 seconds after launch
ChatGPT reached 114 threads
The trial was stopped before resource exhaustion produced another crash

Fresh-helper reset:

Fully quit ChatGPT and all Computer Use helper processes.
Moved the complete local Computer Use helper directory aside; nothing was deleted.
Relaunched build 6744 with the updater disabled during the test.
The app installed a fresh Computer Use helper: 26.817.1000761 (build 1000761).

Result after the reset:

123 live SkyComputerUseService processes by about 27 seconds after launch
ChatGPT reached 169 threads
The trial was stopped before another crash

Control:

Rolled back to ChatGPT Desktop 26.803.41515 (build 6321)
Restored the previous helper
After more than one minute: 1 Computer Use service, 61 ChatGPT threads, and no new crash report

This rules out a stale Computer Use helper as the explanation on this machine. Build 6744 reproduces the unbounded Desktop-managed service/bootstrap lifecycle even after installing its own fresh helper 1000761.

Privacy note: this report intentionally excludes usernames, account details, local paths, session/task identifiers, machine identifiers, crash UUIDs, raw logs, and attachments. Targeted sanitized excerpts can be provided if a maintainer requests specific fields.

I have isolated a strong filesystem trigger for the Computer Use process explosion.

On ChatGPT Desktop 26.818.21641 / build 6849, with my existing ~/.codex implemented as a symlink into my version-controlled dotfiles hierarchy, the previously reported runaway SkyComputerUseService + bundled codex app-server spawning still reproduces and drove the total machine thread count above 13,000.

I first allowed all Desktop-managed plugin/Computer Use runtime updates to finish, quit cleanly, committed those changes, and reproduced again with no further runtime/plugin filesystem mutations. This rules out plugin/runtime reconciliation itself as the continuing trigger.

I then changed only the filesystem topology: removed the top-level ~/.codex symlink and copied the same Codex home contents into a physical ~/.codex directory. Some files/subdirectories inside remain symlinked. With that layout, the same Desktop build has remained stable for 40+ minutes and successfully ran a new Codex thread, with no runaway Computer Use/app-server spawning.

The standalone Codex CLI/TUI continues to operate with the original symlinked layout.

This strongly narrows the initiating trigger to Desktop handling of a symlinked ~/.codex / CODEX_HOME root, likely a lexical-vs-canonical path mismatch in Desktop/Computer Use runtime initialization or service recognition. The already-observed unbounded Computer Use restart/reconciliation behavior then amplifies that initial failure into resource exhaustion.

Independent corroboration: #39420 reports the same Computer Use process explosion with a symlinked ~/.codex, and says removing the symlink avoids it. #39732 independently isolates the same symlink-vs-real-path trigger on 26.818.21641 / build 6849, including an alternating A/B test where the exact same CODEX_HOME data crashes through the symlink path and remains stable through its resolved real path. #38841 reports the same unbounded Computer Use failure mechanism and also notes that ~/.codex is symlinked to an external volume.

On my machine, the regression boundary is 26.810.41047 / build 6570: the same symlinked ~/.codex layout worked normally on the preceding Desktop releases and has reproduced the failure from build 6570 onward. I've used this symlink-based layout since I started using Codex, long before that release, without this behavior.

A quick scan of other open issues also shows multiple App and CLI regressions involving symlink and canonical-path handling. I wouldn't treat these as acceptable regressions in a developer-focused tool.

Symbolic links are a longstanding and fundamental filesystem primitive, and using them to manage configuration is a normal and well-established practice in developer and engineering environments.

A symlinked ~/.codex / CODEX_HOME should therefore work transparently, as it did in previous Codex/Desktop releases and continues to do in the standalone Codex CLI/TUI and other agent harnesses.

Regressing normal filesystem semantics in a developer-focused product is itself a serious compatibility problem. Turning that path-resolution regression into an unbounded SkyComputerUseService / codex app-server process and thread explosion is substantially worse.

Given that this behavior crossed several consecutive Desktop releases and multiple independent users have now isolated the same symlink-related trigger, this also raises a serious regression-test and release-QA concern. A basic test matrix covering physical paths, symlinked CODEX_HOME, symlinked subdirectories, canonical/real paths, and mixed lexical/canonical representations should have caught this class of failure before release.

It is also concerning that this regression has been publicly reproducible for roughly a week across multiple Desktop releases and independent reports without any visible human acknowledgment from OpenAI.

@TahitianBlue

Resolved on my machines — and a correction to my earlier comment

First, retracting something I said above. I claimed the Computer Use runtime version moving
off 26.812.1000717 would be the signal that this was fixed. That was wrong. The runtime moved
to 26.817.1000761 and builds still stormed, as several people here reported. The defect isn't
in the helper runtime — apologies to anyone who used that as a gating heuristic.

What actually fixed it for me: the codex home was reached through a symlink.

Full credit to @TahitianBlue in #39732 for finding this. I can independently replicate it, with
a known-bad control:

`~/.codex`	Result on `26.810.41047`, idle, same machine, same script
symlink → `~/.config/codex`	3 → 73 helpers in 27 seconds, app threads 71 → 138
real directory	1 helper, flat for 903 seconds, threads declining 67 → 60

Same binary, one variable, 33× the time-to-storm. Before the change that machine crashed 7 out
of 7 launches at ~600–680 helpers.

This also explains the multi-machine reports that made some of us suspect account-level or
server-side state. Both of my Macs stormed on one account — but they also share dotfiles, and
both had the identical ~/.codex -> ~/.config/codex layout. Two machines, one dotfile
layout, not one account. Worth checking before reaching for an account theory.

The condition is visible in config without running anything: on my machine the same
hooks.json was registered twice, once under each spelling, and state_5.sqlite held
4,865 thread rows under /Users/mg/.codex/... against 4 under /Users/mg/.config/codex/....
Path strings are compared rather than inodes, so the two spellings never match.

The fix

Make the path the app derives the real one (same-volume rename, instant):

# quit ChatGPT and all codex/Sky helpers first
rm ~/.codex
mv ~/.config/codex ~/.codex
ln -s "$HOME/.codex" ~/.config/codex   # optional compatibility shim

Then canonicalize only the operative path fields — config.toml (project entries,
marketplace source, the Computer Use notify path), .codex-global-state.json, and
state_5.sqlite's threads.rollout_path and threads.cwd. Do not blanket-rewrite: most
occurrences live in threads.title, first_user_message, preview, logs_2.sqlite and
archived_sessions/*.jsonl, which are records of what actually happened. And if your hooks are
registered under both spellings, a naive sed will collapse them into duplicate TOML table keys
and break your config — merge them instead.

Result

Both machines migrated. The main one now runs 26.818.22352 with Computer History enabled
(runtime 26.819.1000816): 1 helper, ~65 threads, flat, zero crashes. No downgrade, no pinning,
no reaper script.

Still an app bug

To be clear, the symlink is a trigger, not the cause. Per #39732's decompilation,
requestComputerUseWorker awaits t.requestFromHost(e) with no timeout and no cap, and its
disposal finally only runs once that settles — so anything that makes the handshake hang leaks
a worker and a V8 isolate permanently. A bounded retry with a circuit breaker would make this
class of trigger harmless. Worth noting one measurable detail for whoever fixes it: killing the
accumulated helpers does release the app's worker threads, so they aren't orphaned — a fix
that merely bounds the loop should reclaim them.

Detail if useful: field report with full measurements
· retrospective, including every wrong turn

@davibusanello

Confirming the symlink finding on my machine — and retracting my account-state attribution.

My ~/.codex had been a symlink into a version-controlled dotfiles directory since mid-May. Converting it to a real directory (same contents; only individual files like config.toml symlinked inward to the dotfiles copies) fully resolved the crash loop on macOS 14.6.1 / ChatGPT Desktop 26.814.41407 (build 6720):

Before: 100+ SkyComputerUseService children by 30 seconds after launch, OOM SIGABRT at 2.5–5.5 minutes, ~20/20 launches.
After: exactly 1 service process, app threads flat at ~59–64, RSS flat ~340MB across a 10-minute monitored run — signed in, full real state, and a second clean run with default features (no computer_use = false).

Two notes for the thread:

Retracting my earlier signed-in/signed-out A/B (my comment above): it was confounded. My "signed-out clean" run had also silently replaced the symlinked codex home with a real app-created directory — two variables moved at once and I credited the wrong one. Auth was not the variable; the topology was. Apologies to anyone who chased account/server-side state on my account of it.
Inner symlinks appear safe, consistent with @davibusanello's report: my config.toml, hooks.json, and hooks directory are symlinks into the dotfiles repo from inside the real ~/.codex, the app writes through them fine, and the launch-time config rewrites did not detach them. Only the top-level symlinked home triggers the storm.

Confirming the top-level Codex-home symlink trigger and unbounded Computer Use bootstrap failure on a newer build.

Environment:

ChatGPT desktop 26.818.31338 (build 6892)
macOS 26.6.2 (25G83), Apple Silicon
CODEX_HOME is unset in both the shell and per-user launchd environment
top-level Codex home: ~/.codex -> .config/codex

The CODEX_HOME=~/.codex value present in local config.toml is scoped only to [mcp_servers.node_repl.env]; it does not configure the desktop app or its managed-service bootstrap.

This machine has six retained ChatGPT crashes across builds 6570, 6662, 6720, and 6892. The latest build was installed at 07:41, launched at 07:43:42, and aborted at 07:45:43.

The latest crash contains 333 threads, including 184 named computer-use threads and all 80 slots at the recorded Dispatch Thread Soft Limit. At least 132 computer-use threads are blocked around synchronous AESendMessage; the common path includes RemoteHostedPIPContentService sendBootstrapToServiceWithProcessIdentifier:rendezvousPort:attempt:. The triggered V8Worker aborts through node::OOMErrorHandler.

The lexical/resolved path split is directly visible in local state:

threads.rollout_path under ~/.codex:          4,150
threads.rollout_path under ~/.config/codex:      23

The config and global-state files also contain both spellings. Unified logs show 57 distinct SkyComputerUseService PIDs in the incident window, and the app created 267 zero-byte per-thread desktop logs within seconds.

This confirms the bug persists in build 6892. The symlink is a trigger, but the product failure is the missing timeout/single-flight/circuit breaker: a path-recognition or service-handshake mismatch must not retain hundreds of worker isolates and synchronous AppleEvent calls until V8 aborts.

I can provide redacted .ips excerpts privately if useful.

Build 6933 retest with a physical top-level Codex home

Following the recent reports about a top-level Codex-home symlink, I ran a controlled retest on the newest production build available to this machine.

Environment:

ChatGPT Desktop 26.818.32112 (build 6933)
Apple Silicon (arm64)
~/.codex was a physical directory, not a top-level symlink
Existing managed contents were still represented by individual symlinks inside that directory

Result approximately 53 seconds after launch:

237 live SkyComputerUseService helpers
218 ChatGPT threads
255 matching ChatGPT/Computer Use workers
About 1.0 GB ChatGPT RSS

The safety monitor terminated the app before resource exhaustion produced a crash, so the crash-report delta remained zero. The worker storm began during startup and it was not safe to attempt a representative Computer Use UI action.

Rollback control:

Restored signed/notarized ChatGPT Desktop 26.803.41515 (build 6321)
Completed a 90-second monitored soak
Exactly 1 Sky helper throughout
ChatGPT threads declined from 67 to 62
App process-tree count stayed flat at 20
RSS settled near 550 MB
Zero new crash reports

Conclusion: making ~/.codex a physical top-level directory was not sufficient to prevent the regression on this machine with build 6933. A top-level symlink may be one trigger, but it is not the only condition capable of reaching the unbounded Computer Use bootstrap/worker failure. This test did retain individual symlinks inside the physical directory, so that distinction may matter for further isolation.

Privacy note: this report excludes usernames, account details, local paths, session/task identifiers, machine identifiers, crash UUIDs, raw logs, and attachments. Targeted sanitized excerpts can be provided if a maintainer requests specific fields.

Another path mismatch worth testing: home-directory capitalisation

One more data point that may be related to the symlink findings.

My .codex directory is not symlinked, but my home directory had a case mismatch:

$HOME:            /Users/example
Canonical path:   /Users/Example

Both paths point to the same inode on the same APFS volume. The mismatch came from the macOS account record, not from anything I configured in ChatGPT.

My Codex configuration also mixed the two spellings. The Computer Use notifier used /Users/Example, while CODEX_HOME, SKY_CUA_SERVICE_PATH and NODE_REPL_TRUSTED_CODE_PATHS used /Users/example.

What I observed:

Build 6415 with runtime 26.804.1000633 was stable with the mixed paths.
Build 6720 with runtime 26.817.1000761 created 459 SkyComputerUseService processes in under five minutes.
I then changed the operative paths to the canonical spelling and set the desktop launch environment to the same CODEX_HOME.
After updating to build 6962 with runtime 26.819.1000816, the app remained stable. Every check showed one helper, the same helper PID was still running nearly eight hours later and a real Computer Use task completed successfully.

The important caveat is that this was not a clean same-build A/B test. I did not rerun build 6720 after changing the paths because the previous test created hundreds of processes. The desktop build and Computer Use runtime also changed, so I cannot say whether the path change, the newer build or both produced the stable result.

I’m not claiming that capitalisation was definitely the cause. It does, however, create the same kind of lexical-versus-resolved path mismatch as a symlink. Case-only path differences on case-insensitive filesystems seem worth adding to the regression test matrix.

Whatever initiates the failure, the Computer Use worker lifecycle still needs a timeout, bounded concurrency, backoff and a circuit breaker.

I found a reliable workaround for this issue on macOS.

The crash appears to be triggered when ~/.codex is a symbolic link and Codex uses the symlink path instead of the resolved physical path.

For example:

~/.codex -> /Volumes/Data/.codex

Both paths point to exactly the same directory, but the Codex app currently appears to treat:

/Users/<user>/.codex

and:

/Volumes/Data/.codex

as different paths in some parts of the app.

This can eventually trigger the runaway computer-use worker/thread leak and crash.

This matches the investigation in #39732, where using the symlink path reproduced the crash consistently, while using the real path for the exact same directory made the app stable.

Workaround

You do not need to remove the ~/.codex symlink.

Instead, explicitly set CODEX_HOME to the resolved physical path.

1. Check whether `~/.codex` is a symlink

ls -ld ~/.codex

For example:

/Users/<user>/.codex -> /Volumes/Data/.codex

2. Get the real physical path

cd ~/.codex && pwd -P

Example:

/Volumes/Data/.codex

Do not use:

/Users/<user>/.codex

as CODEX_HOME, because that is still the symlink path.

Option 1: Set it permanently in `~/.zshrc`

This works on my macOS setup:

echo 'export CODEX_HOME="/Volumes/Data/.codex"' >> ~/.zshrc
source ~/.zshrc

Replace /Volumes/Data/.codex with the output of:

cd ~/.codex && pwd -P

Verify:

echo "$CODEX_HOME"

It should print the real path, for example:

/Volumes/Data/.codex

You can also configure it automatically from the existing symlink:

REAL_CODEX_HOME="$(cd ~/.codex && pwd -P)"
echo "export CODEX_HOME=\"$REAL_CODEX_HOME\"" >> ~/.zshrc
source ~/.zshrc

Option 2: Set it for the macOS GUI session

If the app is launched from Finder/Dock and does not inherit the shell environment, use:

launchctl setenv CODEX_HOME "/Volumes/Data/.codex"

Verify:

launchctl getenv CODEX_HOME

Then completely quit ChatGPT/Codex and reopen it.

For example:

open -a ChatGPT

This is also the workaround demonstrated in #39732:

launchctl setenv CODEX_HOME /Volumes/<SSD>/.codex
open -a ChatGPT

With the symlink path, the issue reproduced consistently; with the resolved real path, the app remained stable.

Recommended setup

My current setup is therefore:

~/.codex -> /Volumes/Data/.codex

The symlink is kept for compatibility, but Codex itself is explicitly given:

CODEX_HOME=/Volumes/Data/.codex

instead of:

CODEX_HOME=/Users/<user>/.codex

In other words:

symlink can remain
        ↓
resolve it with pwd -P
        ↓
set CODEX_HOME to the real path
        ↓
restart Codex/ChatGPT

You can verify both values with:

echo "Shell CODEX_HOME: $CODEX_HOME"
launchctl getenv CODEX_HOME

If necessary:

REAL_CODEX_HOME="$(cd ~/.codex && pwd -P)"

export CODEX_HOME="$REAL_CODEX_HOME"
launchctl setenv CODEX_HOME "$REAL_CODEX_HOME"

echo "Real path:       $REAL_CODEX_HOME"
echo "Shell:           $CODEX_HOME"
echo "launchd session: $(launchctl getenv CODEX_HOME)"

Then completely quit and restart the app.

Why this works

The important part is not moving or changing the .codex data.

The same directory can behave differently depending only on the path string used to access it:

/Users/<user>/.codex          # symlink path -> problematic
/Volumes/<SSD>/.codex         # resolved real path -> stable

The investigation in #39732 reproduced this with the same directory, same inode, and same data. Only the CODEX_HOME path string changed.

The likely permanent fix in Codex itself is to canonicalize CODEX_HOME with realpath() before storing or comparing paths.

Until that is fixed, explicitly setting CODEX_HOME to the physical path is a reliable workaround and allows the existing ~/.codex symlink to remain in place.

Build 7119 same-build retest with explicit GUI `CODEX_HOME`

I tested the workaround from the latest comment on the same Apple Silicon machine and app bundle used for an unset-CODEX_HOME control.

Environment:

ChatGPT Desktop 26.820.60940 (build 7119)
Signed and notarized app bundle
~/.codex is already a physical top-level directory
Individual managed entries inside it remain symlinks
Test value was the exact output of cd ~/.codex && pwd -P
The GUI session value was set with launchctl setenv CODEX_HOME <physical-path> and verified with launchctl getenv CODEX_HOME before a complete app restart

Same-build results at the fourth five-second sample:

Build 7119 condition	Elapsed	Helpers	Matching workers	App threads
`CODEX_HOME` unset	~16 s	27	54	73
GUI `CODEX_HOME` set to physical path	~16 s	26	43	69

The bounded monitor stopped both trials before resource exhaustion. Neither produced a new crash report. After the second trial, signed/notarized build 6321 was restored and remained healthy with one helper; app threads declined from 67 to 61. The temporary launchd value was removed, and I did not persist it in .zshrc.

Conclusion: explicitly setting GUI CODEX_HOME to the physical top-level path was not sufficient on this topology. The workaround may still be effective when the top-level Codex home itself is a symlink, but this same-build A/B suggests an additional trigger remains when the top-level directory is physical and managed entries inside it are symlinked. The missing timeout/single-flight/circuit-breaker behavior remains the product-level failure mode.

Privacy note: this report excludes usernames, local paths, account details, session identifiers, raw logs, and attachments.

Build 7303 no longer reproduces the startup storm with the existing configuration

I ran a guarded retest on the same Apple Silicon machine and Codex-home topology used for my build 6933 and 7119 reports.

Environment:

ChatGPT Desktop 26.825.32147 (build 7303), from the production appcast published August 28
Download size matched the appcast; the bundle passed codesign and notarization assessment
Existing physical top-level ~/.codex with individual managed entries symlinked inward
GUI-session CODEX_HOME unset
Existing configuration unchanged
Bundled Computer Use plugin enabled
Separate legacy mcp_servers.computer-use entry disabled
Node REPL and browser Node REPL configuration retained

Same-machine comparison:

Build and condition	Elapsed	Helpers	Matching workers	App threads	Crash delta
`7119`, same home/config	~16 s	27	54	73	0
`7303`, same home/config	120 s	1	16	61	0

Build 7303 stayed flat for the full two-minute soak. RSS ended at approximately 462 MiB. An additional 45-second check retained the same app PID and helper PID, with one helper, 17 matching workers and 60 app threads. A later live check still showed the same helper PID and no process storm. Startup logs showed enableSparkle=false enableUpdater=false, so the updater was not changing the tested bundle during the run.

Because the real configuration passed, I did not proceed to the prepared empty-home or config-only isolation branches. This result means the existing configuration, including enabled Computer Use plugin metadata and inner symlinks, is not sufficient to trigger the startup regression on build 7303. It is strong local evidence of a build/runtime change, but not proof that every trigger is fixed.

End-to-end caveat: replacing and restarting the app invalidated this thread’s pre-existing Node REPL MCP transport. Follow-up Computer Use calls returned Transport closed before a Finder request was dispatched, so this run verifies startup/process stability only, not a completed representative UI action. I am therefore not calling the upstream issue fully fixed yet.

Build 7303 remains installed. The signed/notarized build 6321 rollback bundle is preserved, and automatic updates remain disabled pending an end-to-end Computer Use action and longer use.

Privacy note: this report excludes usernames, local paths, account details, session identifiers, raw logs and attachments.

Resolved on my machine after updating to the current build.

Environment:

macOS 26.6.2, Apple M4, 24 GB RAM
Before: ChatGPT Desktop 26.818.41509 (build 6962) — hit the Computer Use worker spawn / crash described in this issue
After: ChatGPT Desktop 26.901.22334 (build 7746)

Since updating to build 7746 the app has been stable: no repeated Computer Use worker spawning and no OOM crash during normal use. Consistent with the build 7303 report above, this looks fixed in recent builds.

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.

ChatGPT desktop 26.810.41047 repeatedly spawns Computer Use workers and crashes with V8 OOM on macOS #38455

Description

Activity

github-actions commented on Aug 13, 2026

xyzracehorse commented on Aug 14, 2026

xyzracehorse commented on Aug 14, 2026

andrinur22 commented on Aug 14, 2026

Hyuktae-Kwon commented on Aug 14, 2026

Pippen999 commented on Aug 14, 2026

thesofakillers commented on Aug 14, 2026

abeltesfaye162026-sys commented on Aug 14, 2026

Environment

Reproduction / mitigations already tried

Latest macOS hang report

Earlier crash report

Tygb99 commented on Aug 14, 2026

1. The spawns are spawnSync on the Electron main thread

2. Measured churn — 75 unique children in 14 seconds

3. Before/after the update, same machine, same day

4. Possible trigger — stale plugin app-server copy (hypothesis)

Suggested fix direction

Tygb99 commented on Aug 14, 2026

1. Correction: the main thread is not blocked continuously

2. The caller path — Computer Use worker messages

3. Retracting my plugin-app-server hypothesis as the likely cause

flannick commented on Aug 14, 2026

16 remaining items

davibusanello commented on Aug 19, 2026

ParrotDiceFound commented on Aug 19, 2026

Environment

Signature (matches OP)

Signed-in vs signed-out A/B (controlled, one variable)

Containment from #38744 does NOT hold on 26.814

IgorGanapolsky commented on Aug 19, 2026

jamestjsp commented on Aug 19, 2026

Controlled build 6744 retest with fresh Computer Use helper

davibusanello commented on Aug 20, 2026

galligan commented on Aug 20, 2026

Resolved on my machines — and a correction to my earlier comment

The fix

Result

Still an app bug

ParrotDiceFound commented on Aug 20, 2026

chrisgeo commented on Aug 21, 2026

jamestjsp commented on Aug 21, 2026

Build 6933 retest with a physical top-level Codex home

itskingori commented on Aug 22, 2026

Another path mismatch worth testing: home-directory capitalisation

jarhot1992 commented on Aug 26, 2026

Workaround

1. Check whether ~/.codex is a symlink

2. Get the real physical path

Option 1: Set it permanently in ~/.zshrc

Option 2: Set it for the macOS GUI session

Recommended setup

Why this works

jamestjsp commented on Aug 26, 2026

Build 7119 same-build retest with explicit GUI CODEX_HOME

jamestjsp commented on Aug 28, 2026

Build 7303 no longer reproduces the startup storm with the existing configuration

Tygb99 commented on Sep 4, 2026

celesticlabs commented on Sep 8, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions

1. The spawns are `spawnSync` on the Electron main thread

1. Check whether `~/.codex` is a symlink

Option 1: Set it permanently in `~/.zshrc`

Build 7119 same-build retest with explicit GUI `CODEX_HOME`