New Codex release very untable and high cpu usage on mac, crashes constantly! Please revert

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

• #38468
• #38455
• #38515
• #38589

Powered by Codex Action

Sanitized native diagnostics: reproducible Computer Use worker/thread and app-server storm

I inspected the macOS .ips crash reports and Codex desktop logs. Local usernames, home paths, project/repository names, emails, account identifiers, conversation/thread IDs, session UUIDs, PIDs, crash incident IDs, and tokens have been intentionally omitted.

Executive summary

This is reproducible while no Computer Use task is being invoked. There are now 7 native crashes on app version 26.810.41047 (build 6570). The app survives only 82–147 seconds after launch.

The newest and most useful reproduction occurred after Computer Use was disabled in the UI. The persisted configuration confirmed both:

[plugins."computer-use@openai-bundled"]
enabled = false

[mcp_servers.computer-use]
enabled = false

Despite both settings being false, that launch still produced:

• 324 total threads
• 186 threads named computer-use
• macOS crash-report limit: Dispatch Thread Soft Limit: 64
• 442 [IpcRouter] I am the router messages
• 222 per-thread/session log files, only 2 of them nonempty
• EXC_CRASH / SIGABRT on a thread named computer-use
• node::OOMErrorHandler(...) in the faulting stack
• crash after 96.6 seconds

This demonstrates that disabling Computer Use through the UI does not stop the bundled component involved in this failure.

Environment

• ChatGPT/Codex app: 26.810.41047 (6570)
• Framework: 151.0.7922.137
• macOS: 26.4.1 (25E253)
• Architecture: Apple Silicon, arm64
• CPU: Apple M4
• Physical memory: 24 GiB

The app bundle was replaced by the updater earlier that day. A process that had remained open from before the update continued logging normally for approximately 19 hours. After it exited and the updated binary was launched, every observed launch entered the crash loop.

Reproduction matrix

| Run | Lifetime | Total threads | computer-use threads | Router messages | Log files | Termination | Faulting thread |
|---:|---:|---:|---:|---:|---:|---|---|
| 1 | 104.6 s | 325 | 185 | 432 | 217 | EXC_CRASH / SIGABRT + V8 OOM | V8Worker |
| 2 | 99.0 s | 323 | 185 | 436 | 219 | EXC_CRASH / SIGABRT + V8 OOM | V8Worker |
| 3 | 100.7 s | 327 | 187 | 435 | 218 | EXC_CRASH / SIGABRT + V8 OOM | computer-use |
| 4 | 146.7 s | 320 | 185 | 467 | 228 | EXC_CRASH / SIGABRT + V8 OOM | V8Worker |
| 5 | 86.3 s | 328 | 186 | 435 | 218 | EXC_BREAKPOINT / SIGTRAP | computer-use |
| 6 | 82.4 s | 325 | 185 | 435 | 217 | EXC_CRASH / SIGABRT + V8 OOM | computer-use |
| 7, Computer Use disabled | 96.6 s | 324 | 186 | 442 | 222 | EXC_CRASH / SIGABRT + V8 OOM | computer-use |

Every crash report records the dispatch soft limit as 64. In each report, roughly 149–155 computer-use threads share the same blocked stack shape.

Fault signatures

The reliable portion of the V8 OOM stack is:

__pthread_kill
pthread_kill
abort
node::OOMErrorHandler(char const*, v8::OOMDetails const&)
...
node::worker::Worker::Run()

The dominant blocked computer-use stack is:

__ulock_wait
_dlock_wait
_dispatch_group_wait_slow
AESendMessage
ffi_call_SYSV
CallFunction(Napi::CallbackInfo const&)
...
node::worker::Worker::Run()

The process has the bundled native sky.node and objc/N-API bridge modules loaded. This is a self-initiated Node/V8 abort, not a macOS jetsam or memory-pressure kill.

IPC/log-file storm

The router storm begins almost immediately after each launch and continues until the crash. Depending on the run, the main log records approximately 3.3–5.4 router elections per second.

Each launch also creates 217–228 numbered log files in less than 2.5 minutes. Almost all are zero bytes. The last disabled-Computer-Use run created 222 files in 96.6 seconds. This is consistent with short-lived app-server/worker clients repeatedly starting and re-registering.

After the main app exits, multiple browser_crashpad_handler and hotkey-monitor helper processes can remain behind from prior launches.

Bundled versus installed plugin app-server mismatch

The plugin app-server copy under $CODEX_HOME/plugins/.plugin-appserver/ was not refreshed with the app update and is substantially older than the binaries in the updated application bundle:

| Binary | Copy | Size | Modification time (UTC) | SHA-256 prefix |
|---|---|---:|---|---|
| codex | App bundle | 219,666,000 | 2026-08-14 16:49:57 | 7a26b07855ef9119 |
| codex | Installed plugin app-server | 260,354,320 | 2026-07-11 10:53:08 | e48ce8a0455b97ba |
| codex-code-mode-host | App bundle | 51,495,456 | 2026-08-14 16:49:57 | 206000a48fbe9d2f |
| codex-code-mode-host | Installed plugin app-server | 46,376,032 | 2026-07-11 10:53:07 | 3b7a1a7b4652d7e3 |

Both pairs differ by size and hash. This strongly supports the stale plugin app-server/file-equivalence respawn-loop hypothesis described in #38589, although it does not by itself prove which caller initiates each retry.

Secondary configuration warning

$CODEX_HOME is reached through a symlink to another local volume. The bundled marketplace is stored once using the symlink form and then presented to the app using the canonical form. Logs repeatedly report:

marketplace 'openai-bundled' is already added from a different source

This warning existed during the long stable pre-update process as well, so it is likely secondary rather than the direct crash trigger. It may still be worth normalizing paths during marketplace reconciliation.

Relationship to suggested duplicates

These diagnostics appear to connect three previously reported symptoms of the same 26.810.41047 regression:

• #38455: Computer Use workers accumulate and terminate through node::OOMErrorHandler, including when Computer Use is disabled.
• #38515: approximately 185–187 Computer Use threads, many blocked through AESendMessage, followed by the dispatch-thread limit and V8 abort.
• #38589: IPC router election/log-file storm plus stale, hash-mismatched plugin app-server binaries after the update.

The newest reproduction confirms all three signatures on one machine, and confirms that disabling Computer Use in the current UI is not an effective workaround.

Expected behavior / requested safeguards

• Disabling Computer Use should prevent its bundled worker/service from starting unless another explicitly enabled feature requires it.
• A stale app-server binary or failed equivalence check should be replaced once or fail with bounded exponential backoff.
• App-server launch/reconciliation should never create hundreds of clients/log files or hundreds of blocked threads.
• Hitting a worker, Apple Event, or dispatch-thread limit should fail the affected capability without aborting the entire desktop app.

I can provide a separately sanitized full .ips report if maintainers need one, but have not uploaded the raw report because it contains local filesystem and process metadata.

Additional correlation: #38468 contains a detailed report of the same build and appears highly relevant to this crash signature.

That report measured:

• 157 and then 254 SkyComputerUseService child processes during two launches
• approximately 7–11 GiB aggregate ChatGPT/Codex footprint
• 911 distinct helper PIDs in an eight-minute unified-log window
• repeated socket lock is unavailable errno=35
• Accessibility/TCC failures involving com.openai.sky.CUAService
• the same Dispatch Thread Soft Limit: 64
• high CPU, UI hangs, system-wide input latency, and zombie helpers
• the storm stopping with a fresh Codex state profile

A particularly relevant common factor is that both environments locate $CODEX_HOME through an external-volume path. In this environment it is accessed through a home-directory symlink, producing two textual forms for the same bundled-marketplace location. The newest reproduction still created 186 computer-use threads after Computer Use was disabled in the UI and persisted as enabled = false.

Taken together, #38468 and the native diagnostics above strengthen this working hypothesis:

1. persisted Computer Use/plugin app-server state is stale or path-inequivalent after the update;
2. helper/app-server initialization hits a socket-lock, TCC, or binary-equivalence failure;
3. retry/reconciliation has no effective singleton, backoff, or circuit breaker;
4. short-lived clients repeatedly elect an IPC router while Computer Use workers accumulate;
5. memory, CPU, dispatch threads, and helpers grow until the UI hangs or V8 aborts the entire app.

This also explains why the visible symptoms can vary between high CPU/RAM and system input freezes (#38468), a spawnSync/IPC storm (#38589), and a native V8 OOM with roughly 186 blocked Computer Use threads (this issue, #38455, and #38515).

The detailed sanitized evidence on #38468 is here: https://github.com/openai/codex/issues/38468#issuecomment-5288831133

Correction after reviewing the follow-up investigation on #38455:

The stale, hash-mismatched $CODEX_HOME/plugins/.plugin-appserver/ binaries remain a factual observation, but they should not be treated as the likely caller or root cause of this crash loop. A later sample analysis in #38455 resolves a stronger caller path:

Node Worker (`computer-use`)
→ node::worker::MessagePort::OnMessage(...)
→ main-thread JavaScript handler
→ node::SyncProcessRunner::Spawn(...)
→ child process launch

That analysis also found repeated native menu-state failures such as:

AESendMessage failed with -600
Worker bus disposed for 'computer-use'

This fits the direct evidence here much better: approximately 186 computer-use workers, 149–155 blocked through AESendMessage, hundreds of router elections/log files, and the fault persisting after the visible Computer Use plugin and MCP entry were disabled.

Therefore the primary suspected area should be the bundled Computer Use lifecycle/menu-state retry path. The stale plugin app-server mismatch and marketplace path warning should be considered secondary observations unless maintainers find a separate connection.

The comments on #38455 also show that configuration workarounds are inconsistent: [features] computer_use = false stabilized one environment, while another confirmed the feature false before launch but the desktop app restored the Computer Use notification hook during startup and reproduced the same ~98-second OOM. In the reproduction attached to this issue, the UI/plugin toggle and MCP entry were both false, but the Computer Use notification hook/path remained configured and the crash still occurred.

I am experiencing what appears to be the same issue on macOS, but on Codex App 26.810.50856. The built-in updater confirms this is currently the newest version available to me.

In my case, a long-running conversation began showing “Context automatically compacted” repeatedly, after which Codex became extremely slow and began crashing with “ChatGPT stopped unexpectedly.”

I tested this further:

Restarting the app works, although startup is very slow.
Leaving Codex idle on the home screen remains stable.
Loading/working with the existing long conversation results in instability/crashing.
After restarting again and leaving the existing conversation unopened, simply clicking New chat also caused Codex to crash.
No code was running when that crash occurred.

I have restarted multiple times and confirmed that 26.810.50856 is fully up to date. The issue therefore appears to persist in a newer build than the 26.810.41047 version reported here.

Update: A newer Codex App build became available this morning. I updated from 26.810.50856 to 26.810.52044, but the issue is still occurring.

After installing the update, Codex again crashed with “ChatGPT stopped unexpectedly.” The built-in updater confirms that 26.810.52044 is currently the newest version available.

So, for me, the crash has now been reproduced on both:

26.810.50856
26.810.52044

I have a screenshot showing the crash alongside the “You’re up to date” confirmation for 26.810.52044.

still an issue, constantly crashes after a few minutes @tibo-openai

Confirmed root cause trigger and working mitigation (2026-08-23)

I reproduced the exact failure signature from #38455 on this machine, then isolated a working filesystem-topology fix.

Exact match to #38455

On ChatGPT Desktop 26.818.41509 (build 6962), multiple launches failed after roughly 96–100 seconds, including while idle:

• 321–327 total ChatGPT threads at failure
• 185–186 threads named computer-use
• EXC_CRASH / SIGABRT
• faulting stack through node::OOMErrorHandler(...)
• dispatch-thread soft limit reached
• hundreds of per-thread desktop log files created per launch
• orphaned Crashpad/hotkey helpers left with PPID 1

A live hang sample also reported the dispatch-thread soft limit reached in every sample, with about 202 threads and ~2.1 GiB RSS.

Reinstall and config toggles did not fix it

I backed up and reset the desktop app state, removed generated Computer Use/plugin runtime state, and installed the current official OpenAI-notarized DMG: 26.818.41705 (build 6971). The locally downloaded DMG and the official documentation download were byte-for-byte identical (same SHA-256).

With the top-level Codex-home symlink still present, the clean build reproduced the storm. Removing/locking the SkyComputerUseClient notifier did not prevent it either: the guarded run reached 169 threads and ~1.54 GiB RSS in 41 seconds before I terminated it. This confirms that the notifier and visible plugin settings are symptoms/entry points, not a reliable kill switch.

Trigger on this machine: top-level ~/.codex symlink

The affected layout was:

~/.codex -> /Volumes/<external-volume>/.../.codex

I changed only the Codex-home topology for the next clean run:

1. Kept the old Codex home and all sessions/data safely backed up on the external SSD.
2. Replaced the top-level symlink with a physical ~/.codex directory.
3. Copied auth into the physical directory (no top-level or inner symlinks for the isolation run).
4. Reset the newly generated desktop state once more and launched the same build 6971.

Result:

• 120-second monitored soak completed without a crash
• threads settled at 61–69 instead of climbing past 300
• RSS settled around 455–542 MiB instead of growing past 2 GiB
• CPU returned to low single digits after startup
• no new native crash report
• at four minutes: 62 threads and ~522 MiB RSS

This strongly supports the lexical-versus-canonical Codex-home path mismatch identified in the later #38455 comments. The app appears unable to recognize/reuse the Computer Use service when the Codex-home root is reached through a symlink, then amplifies the handshake/path mismatch into an unbounded worker/bootstrap retry loop.

Keeping worktrees on the external disk without symlinking Codex home

A physical ~/.codex does not require storing managed worktrees on the system disk. I configured the supported worktree root separately:

[desktop]
git-worktree-root = "/Volumes/SSD/repos/worktrees"

This is the same setting exposed under Settings → Worktrees → Worktree root. The Codex home remains a real local directory, while generated worktrees stay on the large external SSD.

Product fix still needed

The physical-directory workaround restores usability here, but a top-level ~/.codex/CODEX_HOME symlink is valid developer filesystem usage and previously worked. The desktop app should canonicalize and consistently compare these paths. Independently, the Computer Use bootstrap lifecycle needs single-flight behavior, bounded retries/backoff, timeouts, and a circuit breaker so any path or AppleEvent failure cannot create hundreds of workers/children or hang the desktop.