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

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

• #37311
• #37493

Powered by Codex Action

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.

好，我根据实际排查到的所有证据给你整理一份可直接提交给官方的 Bug 报告。

---

🐛 Bug 报告（中文版）

标题：ChatGPT macOS 桌面版在启动后 1-2 分钟内因"控制电脑"(Computer Use) 组件无限繁殖进程导致内存耗尽（OOM）闪退

环境

• 应用：ChatGPT 桌面版 26.810.41047（build 6570）
• Codex Framework：151.0.7922.137
• 系统：macOS（Apple 芯片 M4，arm64），16GB 内存
• 触发时间：2026-08-14 自动更新到 build 6570 后开始出现（此前正常）

问题描述
启动 ChatGPT 后，"控制电脑"(computer use / CUA) 组件 SkyComputerUseService 会无限制地繁殖进程，且不会终止：

• 启动 30 秒内即出现 60~90 个进程，5 秒约新增 25 个，数分钟内可累积到 400+ 个（实测 416 个仍在增长）
• 每个进程约占 80MB 内存、持有约 207 个文件描述符，全部进程合计 超过 19GB（远超 16GB 物理内存）
• 主进程最终触发 V8 内存溢出：崩溃日志显示 node::OOMErrorHandler 调用 abort()，异常为 SIGABRT（Abort trap: 6）
• 100% 可复现：每次启动都会发生，最终"打开即闪退"

进程来源与行为

• 应用每次启动都会从应用包内重新拷贝该组件并执行：
• 源：/Applications/ChatGPT.app/Contents/Resources/cua_node/lib/node_modules/@oai/sky/.../Codex Computer Use.app/Contents/MacOS/SkyComputerUseService
• 运行：~/.codex/computer-use/Codex Computer Use.app/Contents/MacOS/SkyComputerUseService
• 每个实例会连接 OpenAI 后端（经本地代理），并连接本地锁定屏授权 socket

次要影响

• 由于这些进程在 Codex 数据目录（~/.codex）持续大量读写，触发 Spotlight（mds/mds_stores）疯狂索引，CPU 占用一度达 200%+，系统整体卡顿

崩溃日志位置
~/Library/Logs/DiagnosticReports/ChatGPT-*.ips（终止原因均为 Abort trap: 6，故障线程含 node::OOMErrorHandler）

已确认的规避方法（供官方复现参考）
将 SkyComputerUseService 二进制替换为立即退出的空程序后，进程不再繁殖、应用稳定运行，但"控制电脑"功能不可用。由此可确认问题出在 Computer Use 组件被重复启动的逻辑（疑似启动/重试失控）。

---

🐛 Bug Report（English, for OpenAI support）

Title: ChatGPT macOS desktop (26.810.41047) crashes with OOM ~1–2 min after launch due to runaway "Computer Use" component spawning

• App: ChatGPT desktop 26.810.41047 (build 6570); Codex Framework 151.0.7922.137; macOS arm64 (Apple M4), 16GB RAM
• Started after auto-update to build 6570 on 2026-08-14.

Behavior: On every launch, the computer-use service SkyComputerUseService spawns endlessly without termination:

• 60–90 processes within 30s; ~25 new per 5s; reaches 400+ within minutes
• Each ~80MB RSS and ~207 open FDs; aggregate >19GB on a 16GB machine
• Main process aborts via V8 OOM (node::OOMErrorHandler → abort()), crash type SIGABRT / "Abort trap: 6"
• 100% reproducible; app effectively crashes on open.

Component: re-copied from bundle each launch from Contents/Resources/cua_node/lib/node_modules/@oai/sky/.../Codex Computer Use.app/Contents/MacOS/SkyComputerUseService, executed from ~/.codex/computer-use/.... Each instance connects to OpenAI backend and holds ~207 FDs.

Crash logs: ~/Library/Logs/DiagnosticReports/ChatGPT-*.ips (all Abort trap: 6; faulting thread shows node::OOMErrorHandler).

Workaround confirmed: replacing the SkyComputerUseService binary with a no-op stops the spawn loop and the app runs stably, but Computer Use becomes unavailable — so the bug is in the repeated-start/retry logic of the Computer Use (CUA) component.

---

ChatGPT/Codex Mac 26.810.41047 creates excessive computer-use threads, crashes repeatedly, and freezes macOS

Description

After updating the ChatGPT/Codex macOS app to 26.810.41047 (6570), the application has become extremely unstable.

ChatGPT repeatedly crashes and, more seriously, causes the entire Mac to become extremely slow or completely unresponsive.

The problem appears to be related to the computer-use functionality. A very large number of computer-use threads are created and become blocked. Eventually, the application crashes and macOS may become effectively unusable.

This is currently blocking my development work completely.

Environment

• ChatGPT/Codex version: 26.810.41047 (6570)
• Identifier: com.openai.codex
• Architecture: ARM64 (Native)
• macOS: 26.6 (25G72)
• Hardware model: Mac17,9
• SIP: Enabled

Symptoms

1. Launch ChatGPT/Codex normally.
2. Use Codex / computer-use functionality.
3. The application begins creating a large number of computer-use threads.
4. System responsiveness progressively deteriorates.
5. ChatGPT eventually crashes.
6. In severe cases, the entire Mac becomes extremely slow or freezes.
7. Restarting macOS only temporarily clears the problem.
8. Relaunching ChatGPT causes the problem to occur again.

Crash Report

The crash report shows:

Triggered by Thread: 328  computer-use

Exception Type:    EXC_BREAKPOINT (SIGTRAP)
Exception Codes:   0x0000000000000001, 0x0000000121f572a0

Termination Reason: Namespace SIGNAL, Code 5, Trace/BPT trap: 5

Dispatch Thread Soft Limit Reached: 75
(too many dispatch threads blocked in synchronous operations)

There are also a very large number of threads named:

Thread XXX:: computer-use

Many of them appear to be blocked around:

__ulock_wait
_dlock_wait
_dispatch_group_wait_slow
AESendMessage
ffi_call_SYSV
node.napi.armv8.node
sky.node
Codex Framework

For example:

Thread 137:: computer-use
0   libsystem_kernel.dylib    __ulock_wait
1   libdispatch.dylib         _dlock_wait
2   libdispatch.dylib         _dispatch_group_wait_slow
3   AE
4   AE
5   AE                        AESendMessage
6   node.napi.armv8.node      ffi_call_SYSV
...
9   sky.node
...
11  Codex Framework

This looks like computer-use workers are accumulating while blocked on synchronous operations until the dispatch-thread soft limit is reached.

Reinstallation Did Not Fix It

I have already:

• Quit and restarted ChatGPT.
• Restarted macOS.
• Downloaded ChatGPT again directly from the official OpenAI website.
• Reinstalled the application completely.

The problem still occurs after reinstalling.

Therefore, this does not appear to be caused by a corrupted application installation.

Expected Behavior

computer-use operations should complete or time out cleanly, and their associated workers/threads should be released.

The application should not continuously accumulate blocked computer-use threads or consume enough system resources to freeze macOS.

Actual Behavior

computer-use threads appear to accumulate until ChatGPT becomes unstable.

The crash report eventually reports:

Dispatch Thread Soft Limit Reached: 75
(too many dispatch threads blocked in synchronous operations)

The crash is also explicitly reported as being triggered by a computer-use thread.

Severity

Critical / Work Blocking

This is not just an isolated application crash. It can degrade the performance of the entire operating system and eventually make the Mac unusable.

I rely heavily on Codex for development work, and this issue has currently brought my normal workflow to a standstill.

Independent reproduction with an additional user-facing input failure and a reversible containment result.

Environment

• ChatGPT Desktop: 26.810.41047 (build 6570)
• Codex Framework / Chromium: 151.0.7922.137
• Computer Use runtime: 26.812.1000717 (build 1000717)
• macOS 15.7.7 (24G720), Apple Silicon
• SIP enabled

Observed behavior

The issue begins without invoking Computer Use. SkyComputerUseService processes are continuously spawned as children of the ChatGPT process and do not exit.

Measured snapshots from one launch:

• 445 helpers, ~17.4 GB aggregate RSS
• shortly afterward: 480 helpers, ~19.6 GB aggregate RSS and ~239% aggregate CPU
• later: 495 helpers, ~18.5 GB aggregate RSS

After a crash/relaunch, the behavior immediately returned: at approximately 2 minutes of app uptime there were already 340 helpers using ~14.4 GB aggregate RSS.

A sampled helper held more than 200 file descriptors, including shared Chromium GPU/WebGPU caches and GCM/LevelDB logs under the Codex application data directory. This explains the accompanying disk churn and secondary indexing activity.

The external connections were owned by the ChatGPT network service / local proxy rather than directly by each helper, but connection churn increased while the spawn loop was active.

Crash evidence

The Apple crash report matches the issue exactly:

• EXC_CRASH (SIGABRT) / Abort trap 6
• crashed thread: computer-use
• Dispatch Thread Soft Limit Reached: 64 (too many dispatch threads blocked in synchronous operations)
• repeated blocked path:

RemoteHostedPIPContentService sendBootstrapToServiceWithProcessIdentifier
→ NSAppleEventDescriptor sendEventWithOptions
→ AESendMessage
→ _dispatch_group_wait_slow

• faulting V8 worker enters node::OOMErrorHandler(...) → abort()

Additional UI impact

Before the crash, the message composer stopped accepting normal keyboard input. The user had to type in another application and paste text into the composer. This persisted while the helper/process leak was active and made the app effectively unusable even before the eventual abort.

Containment result

As a reversible workaround, the managed runtime directory was moved out of its active location (retained as a backup), then only processes whose command exactly matched the old SkyComputerUseService path were terminated. The Computer Use plugin, feature flag, and stale turn-ended notification hook were also disabled with a configuration backup retained.

Result:

• helper count: 495 → 0
• no helper respawn during the observation window
• ChatGPT main process returned to ~1.7% CPU / ~328 MB RSS
• system CPU returned to ~84% idle
• current disk throughput fell to ~0.2–0.4 MB/s
• two orphaned keyboard-monitor helpers from prior crashes were removed while preserving the current app-owned monitor
• the app remained usable, except Computer Use is intentionally unavailable

This strongly suggests an unbounded host-side bootstrap/retry loop, likely aggravated by the host/runtime version mismatch (26.810... host vs. 26.812... CUA runtime). Please add bounded retries/backoff, ensure failed helpers are reaped, validate host/runtime compatibility before launch, and provide a true startup kill switch for Computer Use.

No usernames, personal filesystem paths, session contents, device UUIDs, or full logs/crash reports are included.

I can independently corroborate this issue with substantially more process-level evidence, and I can also confirm that the problem still affects the newer macOS ChatGPT Desktop release 26.810.50856, released after 26.810.41047.

System: M1 Max 64GB macOS 26.6.1

My original incident began immediately after ChatGPT Desktop self-updated from:

• 26.803.81509 — build 6415 — normal
• to 26.810.41047 — build 6570 — affected

I have since updated to:

• 26.810.50856 — still affected

The bundled Computer Use runtime is still:

• 26.812.1000717
• build/runtime 1000717
• plugin/runtime version 1.0.1000717

So the newer Desktop release did not update the Computer Use runtime.

Impact

This is a complete blocker for using the Desktop app safely on my machine.

The affected Desktop builds can rapidly create hundreds of processes and thousands of threads, producing severe CPU/memory pressure and making the system progressively difficult to control.

The standalone Codex CLI remains usable and does not reproduce this Desktop process storm.

I am therefore keeping ChatGPT Desktop closed except for bounded diagnostic reproductions.

Confirmed behavior on 26.810.41047

I collected four affected Desktop runs on 26.810.41047.

The first three produced:

• 207 log fragments over 624 seconds — approximately one every 3.03 s
• 236 fragments over 802 seconds — approximately one every 3.41 s
• 217 fragments over 712 seconds — approximately one every 3.30 s

A fourth post-reinstall run produced:

• 210 fragments over 700 seconds — approximately one every 3.35 s

Normal pre-update runs produced only 2 fragments each.

Critically, these are not primary app-server restart loops.

Each affected run shows:

1. one Desktop-managed primary app-server spawn;
2. successful initialization/handshake;
3. the primary connection remaining alive;
4. no corresponding repeated primary AppServerConnection restart;
5. primary shutdown only when ChatGPT itself is closed.

The uncontrolled process creation happens below/alongside that healthy primary connection.

The Desktop wrapper is not the cause

I reproduced the same failure through two independent CLI routes:

• my existing Desktop wrapper selecting codex-cli 0.147.0;
• ChatGPT's own bundled executable:

/Applications/ChatGPT.app/Contents/Resources/codex

reporting:

codex-cli 0.148.0-alpha.9

Removing the wrapper therefore does not remove the failure.

Historical process counts

Saved process captures from affected runs contain as many as:

• 325 simultaneous SkyComputerUseService processes
• 189 simultaneous bundled stdio app-server processes

The repeated app-server command is exactly:

/Applications/ChatGPT.app/Contents/Resources/codex app-server --listen stdio://

These are actual OS process rows, not inferred counts from log files.

Bounded PPID probe: exact process topology

I subsequently ran a bounded diagnostic capture specifically to resolve process ancestry.

The capture preserved:

• PID
• PPID
• process group
• start time
• elapsed time
• process state
• CPU
• RSS
• full command line

over 30 complete process snapshots.

This definitively resolved the immediate topology.

The observed process tree is:

ChatGPT
├─ one direct host-style Codex app server
└─ many sibling SkyComputerUseService processes
   └─ zero to two bundled:
      codex app-server --listen stdio://
      children per Computer Use service

Representative independent PPID chains included:

ChatGPT PID 7267
  → SkyComputerUseService PID 7950
      → codex app-server PID 8188
      → codex app-server PID 8191

and:

ChatGPT PID 7267
  → SkyComputerUseService PID 9098
      → codex app-server PID 9128

Across all 30 snapshots there were:

0 app-server → app-server PPID edges

So this is not a recursively self-spawning app-server chain.

The immediate fan-out boundary is:

ChatGPT
  → repeated SkyComputerUseService instances
      → bundled stdio Codex app-server children

Growth during the bounded reproduction

The bounded capture shows rapid population growth:

UTC          app servers   Computer Use services
16:15:28          0                  0
16:15:41          1                  0
16:15:53         24                 13
16:16:03         38                 25
16:16:16         39                 46
16:16:30         38                 61
16:16:37         62                 73
16:16:39         54                 76

So within roughly one minute the app had created dozens of independent Computer Use service instances and dozens of downstream stdio app servers.

Approximate summed per-process RSS during the same capture reached:

• app-server family: ~3.26 GiB
• Computer Use service family: ~6.12 GiB

These sums are not unique/private-memory measurements, but they demonstrate the scale of the resource pressure.

trustd: only its CPU spike correlates with the incident

The bounded capture also monitored the system's existing trustd processes to determine whether macOS trust evaluation was involved in the fan-out.

There were six trustd processes throughout the capture. Their existence and process count are not anomalous and are not attributed to ChatGPT:

• the same six trustd PIDs were already running in the pre-launch baseline;
• they are children of PID 1, not descendants of ChatGPT, SkyComputerUseService, or any Codex app server;
• the same processes remained after the complete ChatGPT/Computer Use/app-server process tree disappeared.

The relevant observation is specifically their CPU behavior during the incident.

One pre-existing trustd process reached approximately 97.9% sampled CPU while the Computer Use/app-server fan-out was occurring.

So the distinction is:

trustd processes existing/running
→ normal pre-existing system state

trustd CPU spiking during the process storm
→ incident-correlated secondary behavior

trustd causing or parenting the process storm
→ contradicted by process ancestry

The ancestry evidence therefore rules out trustd as the initiator, parent, or source of the process fan-out.

A plausible secondary explanation is that the extremely high rate of newly launched signed Computer Use and Codex helper processes causes additional macOS trust/code-signing evaluation work, producing the observed trustd CPU spike.

My capture establishes the temporal association and excludes trustd from the fan-out ancestry, but it does not establish that causal mechanism.

Bundle corruption was also ruled out

I created three full logical snapshots of /Applications/ChatGPT.app:

1. before reinstall;
2. immediately after reinstall, before opening ChatGPT;
3. after reinstall and first opening.

All three were the same release/build:

ChatGPT 26.810.41047
build 6570
embedded Codex 0.148.0-alpha.9

The snapshots had:

• identical regular-file hashes;
• identical paths;
• identical Info.plist;
• identical app.asar;
• identical bundled codex;
• successful deep/strict code-sign verification;
• accepted/notarized Gatekeeper assessment.

Reinstalling only reconciled Homebrew/install metadata.

It did not replace a different/corrupt application payload, and the process storm reproduced afterward.

So a damaged app bundle is strongly contradicted.

Apps/MCP/plugin/runtime activity

During affected runs I also observed unusually slow Desktop operations including:

app/installed
~35.97 s
~10.04 s

and:

mcpServerStatus/list
~24.45 s
~13.78 s
~27.91 s
~28.08 s

The affected post-reinstall run also overlapped with:

• bundled Apps/MCP/plugin reconciliation;
• bundled marketplace synchronization;
• automatic primary-runtime installation;
• repeated IPC/router activity.

These make Apps/MCP/plugin/runtime reconciliation a plausible upstream trigger.

However, I do not want to overstate this: the process capture proves the immediate lifecycle topology, but it does not yet prove which Desktop request/source-level function instructs ChatGPT to repeatedly create new SkyComputerUseService instances.

That remains the important missing root-cause step.

What the evidence currently rules out

The evidence now strongly contradicts or rules out:

• primary Desktop-managed app-server crash/restart loop;
• recursive app-server → app-server spawning;
• my Desktop CLI wrapper as a sufficient cause;
• corrupted or partially updated ChatGPT application bundle;
• first-launch modification of the application payload;
• trustd being the parent or initiating source of the fan-out — only its abnormal CPU spike correlates with the incident;
• a static configured MCP command explicitly invoking app-server.

Current working diagnosis

The strongest diagnosis supported by the captures is:

ChatGPT Desktop repeatedly creates/reconciles
SkyComputerUseService instances

→ each Computer Use service initializes one or more
bundled Codex stdio app servers

→ service/app-server population grows without bound

→ process/thread/memory pressure makes Desktop and eventually
the machine unusable

The remaining root-cause question is:

Why does the ChatGPT Desktop process continuously decide that another SkyComputerUseService instance needs to be launched?

That may be in Computer Use lifecycle/reconciliation itself or may be triggered by higher-level Apps/MCP/plugin/runtime orchestration.

Persistence on 26.810.50856

I have now upgraded the macOS ChatGPT app to:

26.810.50856

The issue is still present.

The Computer Use runtime remains unchanged:

1.0.1000717

This is the same Computer Use runtime version present in my fully captured affected 26.810.41047 environment.

I have not yet repeated the complete 30-snapshot PPID capture on 26.810.50856, so I am deliberately not claiming that the exact topology has been independently re-proven on the new Desktop build yet.

What I can confirm is:

• the newer Desktop release still exhibits the problem;
• 1.0.1000717 is still installed;
• the newer Desktop release therefore has not provided a working fix for my environment.

If a short cross-version PPID confirmation on 26.810.50856 would be useful, I can collect one, but I would prefer not to repeatedly reproduce an issue that can create hundreds of processes unless there is a specific diagnostic that maintainers need.

Why I think this belongs in this issue

The symptoms line up closely with the existing reports here:

• idle reproduction;
• rapidly increasing Computer Use workers/threads;
• severe memory/process growth;
• Desktop failure while the standalone CLI remains healthy;
• reinstall does not solve it;
• Computer Use activity occurs even though no intentional Computer Use task is required.

My process captures add direct OS-level ancestry showing that the service fan-out is:

ChatGPT
  → SkyComputerUseService
      → bundled stdio app-server

rather than a recursive app-server chain.

Request to maintainers

Could someone from the team please confirm whether this is being actively investigated?

In particular, I think the useful instrumentation/fix area is the Desktop lifecycle that creates and reconciles SkyComputerUseService instances:

1. identify every call site capable of launching SkyComputerUseService;
2. log the reason/owner/request ID for each launch;
3. enforce one well-defined lifecycle owner or singleton/reference-counted service;
4. prevent another service launch while an equivalent live instance is already initializing/running;
5. add bounded retry/backoff rather than unrestricted relaunch;
6. cleanly drain and terminate service-owned stdio app-server children;
7. verify disabled/unneeded Computer Use state cannot continuously recreate the service;
8. add a regression test that leaves Desktop idle for several minutes and asserts the Computer Use/service/app-server population remains bounded.

I have a substantially more detailed local investigation report, process ancestry data, bundle comparisons, main Desktop logs, and the original bounded snapshots.

The complete raw capture is large and contains local paths/private metadata, so I would prefer to provide narrowly requested sanitized evidence rather than publishing the entire archive.

If there is a specific trace, process sample, log interval, or source-level diagnostic the Desktop/Computer Use team needs, please tell me exactly what would be most useful and I can capture it in a bounded reproduction.

At the moment, the Desktop app is effectively unusable for me since Thursday's release, while the standalone Codex CLI remains my only practical workaround, but far from the same productivity level.

cc @tibo-openai

Additional bounded reproduction on 26.810.50856 (build 6644)

I reproduced the same Computer Use service/process runaway on the newer macOS desktop build and narrowed two independent trigger boundaries.

Environment

• ChatGPT/Codex Desktop: 26.810.50856 (build 6644)
• Bundled Codex CLI: 0.148.0-alpha.9
• Computer Use runtime/plugin: 1.0.1000717
• macOS: 26.6.1, Apple Silicon, 16 GB RAM
• App bundle and Computer Use component both pass code-signing and notarization checks

Normal desktop launch

With both the Computer Use plugin and the explicit computer-use MCP server disabled, a normal LaunchServices launch with no arguments still grows without bound:

main-process threads: 93 -> 149 -> 181 -> ... -> 318
failure time: approximately 108 seconds
crash sample: 322 total threads, 187 named computer-use
termination: SIGABRT through node::OOMErrorHandler

The same behavior reproduced after isolating the two damaged Chromium LevelDB directories and after forcing regeneration of the Computer Use component. This makes profile database corruption and a stale helper bundle unlikely as the primary cause.

Explicit user-data-dir control

Launching the same binary with an explicit profile argument remained stable:

/Applications/ChatGPT.app/Contents/MacOS/ChatGPT \
  --user-data-dir=/path/to/existing/profile

Controls performed:

• clean CODEX_HOME + clean explicit user-data-dir: stable for 5 minutes at about 57-63 threads
• original CODEX_HOME + clean explicit user-data-dir: stable for 3 minutes at about 58-64 threads
• original CODEX_HOME + original full profile passed explicitly: stable for 3 minutes at about 62-72 threads
• final explicit-profile launcher: stable for more than 5 minutes at about 60 threads

The same profile directory used by an ordinary no-argument launch ran away, while passing that directory explicitly remained stable. This suggests a desktop startup/lifecycle regression associated with the no-argument LaunchServices path rather than profile contents.

Isolated Computer Use boundary tests

Each test used a separate profile and a guard that terminated the instance before system-wide memory pressure.

1. Computer Use plugin enabled, explicit Computer Use MCP server disabled:

15 seconds: 147 main-process threads, 104 direct child processes

1. Computer Use plugin disabled, explicit Computer Use MCP server enabled:

10 seconds: 118 main-process threads, 60 direct child processes
20 seconds: 166 main-process threads, 127 direct child processes

This shows that starting the Computer Use service boundary is sufficient to reproduce the runaway; it is not necessary for the visible plugin UI to be enabled.

Independent plugin controls

• Chrome plugin enabled: stable for 150 seconds at 58-61 threads; real extension connection succeeded and a read-only tab-count request completed.
• Record & Replay enabled: stable for 150 seconds; event_stream_status returned successfully without starting a recording.
• In-app Browser enabled: desktop startup remained stable, although navigation timed out in this environment.

These controls suggest the unbounded growth is specific to the Computer Use service lifecycle rather than all browser-related plugins.

Current workaround

• Launch Desktop with an explicit --user-data-dir argument.
• Keep the Computer Use plugin and Computer Use MCP server disabled.
• Chrome can be enabled independently without reproducing the worker storm in the bounded test.

Request

Please instrument and bound the lifecycle that creates/reconciles SkyComputerUseService instances, including:

• a singleton or reference-counted owner;
• deduplication while an equivalent instance is initializing;
• bounded retry/backoff;
• explicit launch-reason/request identifiers;
• cleanup of service-owned stdio app-server children;
• a regression test covering both normal LaunchServices startup and explicit --user-data-dir startup.

Raw crash reports and local logs are preserved but intentionally not attached publicly because they contain local paths and metadata. Sanitized excerpts can be provided if maintainers request a specific trace.

Independent reproduction with socket-level evidence for the same failure.

Environment

• ChatGPT Desktop 26.810.41047 (build 6570)
• macOS 26.6.1, Apple Silicon M4
• Computer Use disabled in both the bundled plugin and MCP server config

Reproduction

The app crashes while idle after roughly 90 seconds. Instrumented launches showed:

0s:     1 main-process thread
5s:    71
25s:  177
60s:  276
85s:  319
then: V8 abort

The Apple crash reports contain 319 to 325 total threads, with 184 to 188 named computer-use. The termination path is SIGABRT or SIGTRAP through node::OOMErrorHandler.

A clean --user-data-dir and a temporary empty CODEX_HOME both reproduced the growth. This rules out the normal Chromium profile and the user's Codex/plugin config as required causes.

Socket and process evidence

During the runaway, ChatGPT repeatedly launched SkyComputerUseService processes. One instance owned:

~/Library/Group Containers/2DC432GLL2.com.openai.sky.CUAService/IPC/computeruse.sock
~/Library/Group Containers/2DC432GLL2.com.openai.sky.CUAService/IPC/computeruse.sock.lock

The other service instances repeatedly logged:

socket lock is unavailable errno=35

The same interval also contained repeated Bad file descriptor and NSPOSIXErrorDomain Code=9 errors. New computer-use workers continued to appear while those service launches failed to acquire the socket lock.

The immediate failure chain appears to be:

ChatGPT launches another SkyComputerUseService
  -> existing instance already owns computeruse.sock
  -> new instance can't acquire the socket lock
  -> waiting computer-use worker remains alive
  -> workers accumulate until V8 aborts

Disabling the visible Computer Use feature doesn't stop this shared service lifecycle on the affected build.

This evidence points to missing deduplication or backoff around service startup. A single lifecycle owner, plus a bounded retry when computeruse.sock is already owned, should prevent the process and worker storm. I preserved the crash reports and can provide narrow sanitized log excerpts if maintainers need them.

Independent reproduction on ChatGPT Desktop 26.810.52044 (build 6662), macOS:

• The app crashes after displaying Dispatch Thread Soft Limit Reached.
• ps aux | grep -Ei 'ChatGPT|Codex' | grep -v grep | wc -l returned 319 ChatGPT/Codex-related processes.
• syspolicyd was not under pressure at the time: approximately 2.5% CPU, 0.1% memory, and 36 open files.
• The affected installation is /Applications/ChatGPT.app (merged desktop app), with Codex Framework 151.0.7922.137.
• The process list included many accumulated browser_crashpad_handler and bare-modifier-monitor processes from multiple launch times.

Bundle version:

CFBundleShortVersionString: 26.810.52044
CFBundleVersion: 6662

This appears consistent with the same unbounded Computer Use worker/helper lifecycle and orphan-helper cleanup problem described here. I do not yet have a sanitized .ips report, so I am limiting this comment to directly observed evidence.

Reproduced on two Macs. Rather than add another repro, here are four things I haven't seen posted yet — two of them actionable for anyone who has already worked around this.

⚠️ 1. Downgrading does not stick: the app re-arms its own update

This is the one I'd flag hardest, because several people here have downgraded and may be silently exposed.

After rolling back and setting:

defaults write com.openai.codex SUEnableAutomaticChecks -bool false
defaults write com.openai.codex SUAutomaticallyUpdate -bool false

I re-checked two days later. Both keys had been reset to 1, SULastCheckTime showed a fresh check, and 26.810.52044 was fully downloaded (1.9 GB) and staged in:

~/Library/Caches/com.openai.codex/org.sparkle-project.Sparkle/Installation/

armed to install on next quit. The only reason it hadn't landed is that the app happened to have 39 hours of uptime. The app rewrites its own preferences domain, the same way it rewrites ~/.codex/config.toml on launch.

If you have downgraded, check both:

defaults read com.openai.codex SUEnableAutomaticChecks   # want 0
ls ~/Library/Caches/com.openai.codex/org.sparkle-project.Sparkle/Installation 2>/dev/null   # want empty

Given the kernel panics in #38760 / #38697, silently getting re-updated is not a small problem.

2. Reaping the helpers keeps the app alive indefinitely

A stopgap for anyone who can't downgrade. Killing the accumulated helpers does release the app's worker threads, so the app never reaches the ceiling:

while true; do
  if pgrep -x ChatGPT >/dev/null 2>&1; then
    n=$(pgrep -f SkyComputerUseService | wc -l | tr -d ' ')
    [ "$n" -gt 10 ] && pkill -f SkyComputerUseService
  fi
  sleep 20
done

Verified over 10.5 minutes under a launchd agent: helper count capped at 25–37, app thread count plateaued ~105 and then declined to ~90, no crash. Without it the same machine died in ~4 minutes, every time. Costs ~20–50% of one core in permanent churn — a bridge, not a home, but it makes the app usable.

This also says something about the leak: the worker threads are not orphaned from their child processes, so a fix that simply bounded/cleaned up the spawn loop would reclaim them.

3. The two point releases did not touch the bug (binary comparison)

Comparing 26.810.41047 against 26.810.52044 locally:

| | 41047 | 52044 |
|---|---|---|
| Contents/Resources/native/sky.node | 1210752 bytes, 1e468ee72cc1e402… | 1210752 bytes, b6248745c81c7013… |
| embedded codex-cli | 0.148.0-alpha.9 | 0.148.0-alpha.9 |
| Computer Use runtime | 26.812.1000717 | 26.812.1000717 |

So the native module was rebuilt (identical size, different hash) but the embedded CLI and the Computer Use runtime are unchanged — consistent with everyone's reports that 50856 and 52044 are still affected. A Desktop version bump is not a signal here; the Computer Use runtime version moving off 26.812.1000717 is.

4. Ruled out locally — including a clean-room test

Each applied, then re-tested with a clean relaunch and process monitoring. None changed the spawn rate:

• Full tccutil reset Accessibility for the app and helper bundle IDs, then granting the Accessibility prompt when it appeared, and re-adding "Codex Computer Use" to Screen Recording. (Permissions are unrelated to the crash.)
• Settings-UI toggles for Computer Use and Computer History.
• [features] computer_use = false — accepted to the point that the app strips its own [mcp_servers.computer-use] and [plugins."computer-use@openai-bundled"] entries on next launch, and spawns anyway.
• [desktop] computerUseAlwaysHidePictureInPicture = true (the workaround that helped the 26.730 PiP variant).
• Deleting ~/.codex/computer-use/ — re-provisioned within seconds of launch.
• Clean room: killed every codex-family process system-wide (app, app-server, helpers, orphans) plus unrelated agents, verified zero, then relaunched — stormed identically, 4 → 101 helpers in 60 seconds. The loop requires nothing outside the app binary.

Environment / measurements

• Two Apple Silicon Macs (Studio, mini), both 26.810.41047.
• macOS 26.6 (25G70) and macOS 27.0 beta (26A5406e) — identical behavior; the first crashes are stamped 26.6 and the rest 27.0, so the OS is not a variable. I haven't seen 27.0 reported here yet.
• ~2 helpers/sec from launch while idle, accelerating to ~6/sec. Helpers stay alive and accumulate (ages evenly spread). App thread count grows ~1:1 with spawns.
• Crash at ~600–682 concurrent helpers, ~4–4.5 min after launch, 7/7 times.
• Signature: EXC_BREAKPOINT (SIGTRAP) (twice SIGABRT) on a thread named computer-use, bottom frames node::worker::Worker::Run() → node::NewIsolate() → v8::Isolate::Initialize() — i.e. the fatal abort lands on isolate creation, a slightly different presentation from the node::OOMErrorHandler path reported above, but the same resource-exhaustion family.

Rolled back to 26.727.51351, which has been completely clean (39h uptime, 1 helper, 0 crashes). Note that some rollback recommendations here point at 26.803.x, which has its own crash-on-launch report in #38037 — worth going further back.

Corroborating this exact Computer Use worker/thread-exhaustion failure on the newer desktop build.

Environment

• ChatGPT desktop: 26.810.52044 (build 6662)
• Codex Framework: 151.0.7922.137
• macOS: 26.6.1 (25G76)
• Apple Silicon, Mac15,7, ARM64

Reproduction

• The app crashes on every launch, including when left completely idle.
• The attached incident crashed approximately 149 seconds after launch.
• The crash loop began immediately after the ChatGPT/framework update. macOS was updated in approximately the same time window, so I cannot conclusively isolate those two changes.
• A full macOS reboot did not help.

Crash evidence

• Dispatch Thread Soft Limit Reached: 64
• Approximately 323 total threads
• 187 threads named computer-use
• Repeated blocked path: AESendMessage → NSAppleEventDescriptor sendEventWithOptions → RemoteHostedPIPContentService sendBootstrapToServiceWithProcessIdentifier
• Triggered thread: 321, named computer-use
• Exception: EXC_BREAKPOINT (SIGTRAP), rather than the SIGABRT/node::OOMErrorHandler termination in the original report
• The failing worker was initializing another Node/V8 isolate and includes reading_mode...parse_distilled_html / v8::CppHeap frames

This looks like the same unbounded Computer Use worker/bootstrap retry, but it demonstrates that build 6662 can reach a dispatch-thread/SIGTRAP terminal failure without first surfacing as the conventional V8 OOM signature.

Sanitized full crash report (Crash Reporter Key redacted):

chatgpt-macos-crash-26.810.52044-sanitized.txt

Corroborating this failure with a controlled rollback test on the newer build train.

Environment

• ChatGPT desktop: 26.810.52044 (build 6662)
• Codex Framework: 151.0.7922.137
• macOS: 26.4.1 (25E253)
• Apple Silicon / arm64

Crash evidence on build 6662

The app repeatedly entered a startup crash loop. The latest two inspected macOS crash reports had:

• EXC_CRASH / SIGABRT
• node::OOMErrorHandler → abort()
• approximately 313 total threads
• 185–186 threads named computer-use

Seven ChatGPT/Codex diagnostic reports are currently present on this machine. Raw reports are not attached because they contain local process and path information.

Controlled rollback still reproduces

I downloaded the official arm64 ZIP for 26.810.50856 (build 6644), verified its deep code signature and Apple notarization, then launched it against the original user profile.

The startup storm reproduced immediately:

| Relative sample time | Main-process threads | RSS (KiB) | Per-thread log files | [IpcRouter] I am the router |
|---:|---:|---:|---:|---:|
| 0 s | 161 | 949376 | 68 | 136 |
| 10 s | 190 | 902880 | 97 | 194 |
| 21 s | 217 | 807120 | 125 | 248 |
| 31 s | 241 | 467536 | 147 | 293 |

The process was force-quit at 241 threads to avoid another OOM, so this rollback run intentionally produced no new crash report. Build 6662 was then restored and left stopped.

This is also consistent with the per-thread log and router-election storm reported in #38589.

Recovery attempts that did not provide a usable path

• Disabling the bundled Browser and Computer Use plugins plus the local node_repl server in config did not stop the startup storm; the desktop app still initialized its internal Browser/Computer Use runtime. The original config was restored after the test.
• Launching with --disable-gpu did not help.
• Launching with a fresh Electron profile mounted the app routes in logs, but the window remained black and unusable.

Conclusion

This machine reproduces the same Computer Use worker/thread-exhaustion failure on both build 6662 and the immediately preceding build 6644. Therefore 26.810.50856 is not a safe rollback target for this failure. The CLI remains the practical workaround while the desktop app stays stopped.

I can provide sanitized log excerpts or crash reports if maintainers specify the exact fields needed.

Confirmed failure on 26.810.52044 (build 6662) after real interaction

I tested the current production build on the same affected Mac. A three-minute idle control initially appeared stable, but real interaction immediately reproduced the original failure twice.

Fresh crash evidence

Both crashes were generated by the installed production app:

• ChatGPT/Codex Desktop: 26.810.52044 (build 6662)
• Crash 1: EXC_CRASH / SIGABRT, 320 total threads, 186 named computer-use; faulting thread 319 was computer-use
• Crash 2: EXC_CRASH / SIGABRT, 318 total threads, 187 named computer-use; faulting thread was V8Worker
• The reports again contain repeated RemoteHostedPIPContentService → AESendMessage waits and node::OOMErrorHandler in the Computer Use worker path

This is the same resource-exhaustion signature as the earlier affected builds. The idle-only test was therefore a false negative; actual use is required for a meaningful regression test.

Control still holds

The same build launched with an explicit --user-data-dir remains stable with roughly 65 threads, 9 direct children, and a single SkyComputerUseService instance.

Conclusion

Build 6662 has not fixed this issue on this machine. Please include an interaction-driven regression test in addition to idle startup coverage, and keep the Computer Use service/worker population bounded across both normal LaunchServices startup and explicit-profile startup.

The two raw macOS reports are preserved locally but are not attached publicly because they contain local metadata. Sanitized excerpts can be provided if a maintainer requests specific fields.

Independent reproduction with state-reset A/B evidence

Environment:

• ChatGPT/Codex Desktop 26.810.52044 (build 6662)
• Also reproduced on 26.810.41047 (build 6570)
• macOS 26.4 (25E246), Apple Silicon, 24 GB RAM

Observed:

• At least 16 matching macOS crash reports across the two builds.
• Ordinary launches crash while idle after roughly 59–95 seconds; no browser or Computer Use task is started.
• Latest crash occurred after 59 seconds with 332 total threads, including 186 threads named computer-use.
• The faulting thread was V8Worker; the report records EXC_CRASH / SIGABRT and node::OOMErrorHandler leading to abort.
• System memory was not under pressure (about 73% free immediately after reproduction).

Controlled state-reset test:

1. Quit the app and quarantined all archived sessions without deleting them.
2. Moved the complete thread-state SQLite set aside and relaunched. The rebuilt database indexed 35 threads instead of the prior 202.
3. The app still emitted rapidly increasing [IpcRouter] I am the router entries: 199 at t+24s, 281 at t+34s, 357 at t+44s, and 423 at t+54s, then crashed at about t+59s.
4. Restored the original state after the test.

The same failure also reproduced with a fresh Electron --user-data-dir. Disabling the browser and Computer Use plugins and testing with default configuration did not stop it.

This evidence appears to rule out thread-history volume, corrupt local thread state, plugin enablement, Electron profile state, and host memory pressure. It is consistent with an unbounded Computer Use worker/router lifecycle while the app is idle.

I have not attached raw diagnostic reports because they contain local paths and metadata. I can provide targeted, sanitized excerpts if maintainers request specific fields.

Update: working containment

Adding the following to the active Codex configuration stopped the worker proliferation:

[features]
computer_use = false

Two controlled launches remained stable:

• A minimal authenticated Codex home stayed alive for 2 minutes 39 seconds with 61 threads and zero computer-use-named threads.
• The full original Codex home, with all existing thread state restored, stayed alive for more than 4 minutes. A subsequent normal Finder/Dock-style relaunch also remained alive for 120 seconds with 63 threads, zero computer-use-named threads, and no new crash report.

For comparison, uncontained launches consistently crashed within 59–95 seconds and the latest had 186 computer-use threads. This workaround disables Computer Use, but leaves the rest of the desktop app usable in this reproduction.

Update — controlled re-enable test on macOS desktop 26.814.41407 (build 6720)

I re-enabled Computer Use after updating the desktop app, and the same runaway behavior reproduced almost immediately. Within a short period, the network monitor showed:

• TCP: 23,326
• UDP: 1,252
• The adjacent JS counters displayed: 3,059 and 109

This was not a normal sustained Computer Use workload. The ChatGPT process began spawning large numbers of SkyComputerUseService helpers again, with the same resource-exhaustion pattern reported above. The test was aborted as soon as the runaway behavior was clear.

Please treat this as evidence that the 26.814.41407 update does not provide a safe mitigation for this issue, or at minimum that the fix status is unclear. Please confirm:

1. Is there a supported way to disable the Computer Use bootstrap/notify hook so the setting survives relaunch?
2. Which exact desktop/helper build contains the fix?
3. Can failed helpers be capped and reaped so a short session cannot create thousands of connections?

No usernames, personal paths, session contents, device UUIDs, or complete local logs are included.

Update: still reproducible on 26.814.41407 / build 6720 with updated Codex and updated Computer Use runtime

I have now reproduced the same process-fan-out failure on the newer macOS ChatGPT Desktop release:

• ChatGPT Desktop: 26.814.41407 — build 6720
• Embedded Codex CLI: 0.148.0-alpha.15
• Computer Use runtime: 26.817.1000761 — build 1000761
• macOS: 26.6.2 (25G83), Apple Silicon

This is an important new boundary because, unlike the previous 26.810.x updates, the Desktop app, embedded Codex CLI, and Computer Use runtime have all changed, yet the failure persists.

I captured another bounded 30-sample PID/PPID series. The immediate topology is unchanged:

PID 1
└─ ChatGPT
   ├─ one direct Code Mode host app server
   └─ many sibling SkyComputerUseService processes
      └─ zero to two bundled
         codex app-server --listen stdio://
         children per service

Across the complete capture:

• all 2306 sampled SkyComputerUseService observations were direct children of ChatGPT;
• all 947 sampled bundled stdio app-server observations were direct children of a SkyComputerUseService;
• there were zero app-server → app-server parent edges;
• the final/peak live sample contained:
• 134 SkyComputerUseService processes;
• 95 bundled stdio app servers;
• one normal direct Code Mode host app server.

This reproduces the same topology previously captured on builds 6570 and 6662, but at a larger observed population.

The Desktop-managed primary app server is still not crash-looping: the saved Desktop logs record one primary stdio spawn, successful initialization, normal persistence through the capture, and one teardown stop. The runaway processes are subordinate Computer Use services and their stdio app-server children.

After ChatGPT itself and its direct Code Mode host had exited, the saved post-quit snapshot still contained:

• 111 bundled codex app-server --listen stdio:// processes
• 1 SkyComputerUseService, reparented to PID 1

The unified-log capture independently recorded 139 distinct SkyComputerUseService PIDs performing process-manager CHECKIN events during the reproduction window, consistent with the process snapshots showing continuous creation of new Computer Use services.

At this point the affected build boundary I have directly captured is:

26.803.81509 / build 6415 -> known good

26.810.41047 / build 6570 -> broken

26.810.52044 / build 6662 -> broken

26.814.41407 / build 6720 -> broken

And importantly:

embedded Codex:
0.148.0-alpha.9  →  0.148.0-alpha.15

Computer Use runtime:
26.812.1000717  →  26.817.1000761

result: still broken

This rules out the previously shipped embedded Codex build and Computer Use runtime version as sufficient causes on their own.

The strongest remaining defect boundary is the ChatGPT Desktop-managed Computer Use lifecycle: service creation, readiness/reuse, reconciliation, and cleanup.

The unresolved question is no longer process ancestry—we now have the same PPID topology across multiple releases. The unresolved question is:

What Desktop lifecycle/reconciliation path repeatedly decides that a new SkyComputerUseService must be created instead of recognizing, awaiting readiness of, or reusing an existing/starting service?

Still broken on ChatGPT App 26.814.41957 Released Aug 18, 2026

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:

1. Fully quit ChatGPT and all Computer Use helper processes.
2. Moved the complete local Computer Use helper directory aside; nothing was deleted.
3. Relaunched build 6744 with the updater disabled during the test.
4. 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.

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

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:

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