›_ Codex Issues
Codex Issues / #38939

CRITICAL / App-Unusable: Codex macOS Spawns Runaway computer-use Threads Until Dispatch Thread Exhaustion and Fatal V8 OOM Crash

Resolved 💬 9 comments Opened Aug 17, 2026 by jarhot1992 Closed Aug 28, 2026
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

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

26.810.52044 (6662)

What subscription do you have?

Pro

What platform is your computer?

Darwin 25.5.0 arm64 arm

What issue are you seeing?

Translated Report (Full Report Below)
-------------------------------------
Process: ChatGPT [65580]
Path: /Applications/ChatGPT.app/Contents/MacOS/ChatGPT
Identifier: com.openai.codex
Version: 26.810.52044 (6662)
Code Type: ARM-64 (Native)
Role: Foreground
Parent Process: launchd [1]
Coalition: com.openai.codex [1509]
User ID: 501

Date/Time: 2026-08-16 20:40:35.5802 -0700
Launch Time: 2026-08-16 20:39:08.7702 -0700
Hardware Model: Mac16,10
OS Version: macOS 26.5.2 (25F84)
Release Type: User

Time Awake Since Boot: 5700 seconds

System Integrity Protection: enabled

Triggered by Thread: 10 V8Worker

Exception Type: EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000

Termination Reason: Namespace SIGNAL, Code 6, Abort trap: 6
Terminating Process: ChatGPT [65580]

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

Application Specific Information:
abort() called

log.txt

What steps can reproduce the bug?

You can reproduce the issue very reliably with the following steps:

Launch the Codex macOS desktop app normally.
Do not perform any special configuration changes. The issue still occurs even after removing ~/.codex/config.toml.
Leave the app running for roughly 1–2 minutes.
Observe the ChatGPT/Codex process thread count continuously increasing instead of stabilizing. In my case it grows from around 200 threads to 250–300+ threads within a short period.
The application then becomes increasingly unstable and crashes consistently.
The crash report shows that a large number of computer-use workers are blocked in synchronous Apple Event / RemoteHostedPIPContentService calls, eventually hitting:
Dispatch Thread Soft Limit Reached: 64 (too many dispatch threads blocked in synchronous operations)
Shortly afterward, the app terminates with SIGABRT from node::OOMErrorHandler, making Codex effectively unusable because the crash can recur shortly after every launch.

This appears to be a severe, reproducible runaway worker/thread leak rather than an isolated crash or configuration issue. In the attached crash report, the app launched at 20:39:08 and crashed at 20:40:35—about 87 seconds later. The report also explicitly records the dispatch-thread exhaustion and abort() condition.

What is the expected behavior?

_No response_

Additional information

_No response_

View original on GitHub ↗

9 Comments

github-actions[bot] contributor · 11 days ago

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

  • #38813
  • #38771
  • #38744
  • #38515
  • #38455

Powered by Codex Action

AlbertArredondoAlfaro · 10 days ago

Same issue here

ManuLpz4 · 9 days ago

Same issue here

zhougit-hue · 7 days ago

same issue here

andrinur22 · 7 days ago

Same issue here

jarhot1992 · 4 days ago

The crash problem is still present in the latest version. After updating to the newest release, the application continues to crash frequently and the issue remains fully reproducible.

This bug significantly impacts normal usage, as the application becomes unstable and cannot be reliably used. Please investigate the root cause based on the crash reports and prioritize a fix.

setten-QB · 2 days ago

Same leak on macOS 15.7.9 (Sequoia), so this is not specific to macOS 26.5.2 — the open question in the community thread.

Env: ChatGPT desktop 26.810.52044 (build 6662), com.openai.codex, Apple Silicon, ARM-64 native, macOS 15.7.9 (24G830).

Crashed Thread:        334  computer-use
Exception Type:        EXC_BREAKPOINT (SIGTRAP)
Termination Reason:    Namespace SIGNAL, Code 5 Trace/BPT trap: 5
Dispatch Thread Soft Limit Reached: 80 (too many dispatch threads blocked in synchronous operations)

Growth, sampled every 10s, app launched and left completely idle:

| time | threads | RSS |
| --- | --- | --- |
| 21:49:26 | 215 | 2,657 MB |
| 21:49:36 | 257 | 3,865 MB |
| 21:49:46 | 300 | 5,110 MB |
| 21:49:56 | — | process gone |

That is ~4.2 threads/sec and ~122 MB/sec, with an identical slope across both intervals — strictly linear, no plateau.

Possible signal: my rate is ~1.7x the previously reported 2.5 threads/sec and 70 MB/sec, and my dispatch soft limit is 80 rather than 64. If the spawn rate scales with dispatch width or core count, the loop may be driven by available concurrency rather than a fixed timer.

jarhot1992 · 2 days ago
Same leak on macOS 15.7.9 (Sequoia), so this is not specific to macOS 26.5.2 — the open question in the community thread. Env: ChatGPT desktop 26.810.52044 (build 6662), com.openai.codex, Apple Silicon, ARM-64 native, macOS 15.7.9 (24G830). `` Crashed Thread: 334 computer-use Exception Type: EXC_BREAKPOINT (SIGTRAP) Termination Reason: Namespace SIGNAL, Code 5 Trace/BPT trap: 5 Dispatch Thread Soft Limit Reached: 80 (too many dispatch threads blocked in synchronous operations) `` Growth, sampled every 10s, app launched and left completely idle: time threads RSS 21:49:26 215 2,657 MB 21:49:36 257 3,865 MB 21:49:46 300 5,110 MB 21:49:56 — process gone That is ~4.2 threads/sec and ~122 MB/sec, with an identical slope across both intervals — strictly linear, no plateau. Possible signal: my rate is ~1.7x the previously reported 2.5 threads/sec and 70 MB/sec, and my dispatch soft limit is 80 rather than 64. If the spawn rate scales with dispatch width or core count, the loop may be driven by available concurrency rather than a fixed timer.

At this point, this bug has been going on for three weeks, so I’m starting to develop a slightly ridiculous theory:

Maybe nobody inside OpenAI actually uses Codex for day-to-day development or testing — perhaps everyone has quietly switched to Claude Code. 😄

jarhot1992 · 1 day ago

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.