SIGTRAP in v8::Isolate::New (CodeRange::InitReservation → SetPermissions) on macOS 26 Intel — regression in 0.141.0 (0.140.0 works)

Open 💬 14 comments Opened Jun 19, 2026 by ahnjunwoo

💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

On an Intel Mac running macOS 26.5.1, codex 0.141.0 crashes with SIGTRAP (EXC_BREAKPOINT, exit 133) the moment any tool/skill is invoked. The process self-aborts inside the embedded V8 engine while initializing a new Isolate. Downgrading to 0.140.0 fixes it completely — so this is a regression introduced in 0.141.0.

The crash happens during normal use whenever the model first runs a tool (shell exec, skill invocation, etc.). The TUI dies hard, and because it doesn't restore terminal modes on the way out, it leaves the terminal in a broken state (kitty-keyboard/mouse escape sequences echoed as shell input).

Environment

codex-cli 0.141.0 (Homebrew cask, codex-x86_64-apple-darwin, signed by OpenAI Developer ID, hardened runtime, com.apple.security.cs.allow-jit entitlement present)
macOS 26.5.1, Intel Core i7-9750H (x86_64) — native Intel, not Rosetta
Terminal: Ghostty 1.3.1
codex doctor: all green (DBs healthy, auth ok, git ok)
ulimit: address space / data / locked-memory all unlimited
No DYLD_* / V8_FLAGS / MALLOC_* env interference

Reliable repro

codex exec --sandbox read-only "Run the shell command: echo hi. Then report output."

0.141.0 → prints the reasoning preamble, then dies. Exit code 133 (128 + SIGTRAP). A crash report is written to ~/Library/Logs/DiagnosticReports/codex-x86_64-apple-darwin-*.ips.
0.140.0 → tool runs, exit code 0, normal output.

A prompt that does not trigger a tool call (e.g. "Reply with exactly: SMOKE_OK, no tools") does not crash on 0.141 — confirming the trigger is the first tool/skill invocation (i.e. first V8 Isolate creation in the code-mode exec runtime).

Crash signature (identical across ~15 reports)

EXC_BREAKPOINT (SIGTRAP), codes 0x2 / 0x0

v8::base::OS::SetPermissions(void*, unsigned long, ...)
v8::internal::CodeRange::InitReservation(v8::PageAllocator*, ...)
v8::internal::Heap::SetUp(v8::internal::LocalHeap*)
v8::internal::Isolate::Init(...)
v8::internal::Isolate::InitWithSnapshot(...)
v8::internal::Snapshot::Initialize(v8::internal::Isolate*)
v8::Isolate::Initialize(...)
v8::Isolate::New(...)
v8::isolate::Isolate::new::h...        (rusty_v8 binding)
std::sys::backtrace::__rust_begin_short_backtrace
_pthread_start / thread_start

v8::base::OS::SetPermissions is failing (returns false) while reserving the JIT code range, and V8's CHECK turns that into a ud2 → EXC_BREAKPOINT. So V8 cannot set up an executable code range on this OS/arch for the 0.141 build, and the failure is handled by aborting instead of degrading.

Notes / possible angles

The JIT entitlement is present and the binary is properly signed, so this isn't a missing-entitlement issue at the codex level — it looks like the bundled V8 in 0.141 can't establish its code range on macOS 26 / Intel.
Likely candidates: the V8 version bump or code-range / --jitless defaults changed between 0.140 → 0.141, or a new macOS 26 executable-memory restriction the 0.140 V8 tolerated and the 0.141 V8 does not.
Minor secondary bug: on this crash the TUI doesn't reset terminal modes (kitty keyboard / mouse reporting stay enabled), leaving the shell unusable until reset.

Workaround

Pin to 0.140.0 (npm i -g @openai/codex@0.140.0).

I'm happy to attach a full .ips crash report or test patches/builds.

View original on GitHub ↗

14 Comments

github-actions[bot] contributor · 1 month ago

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

#29000
#28893

Powered by Codex Action

dmitryjum · 1 month ago

I've experienced the same issue in both Codex CLI and VS Code extension. My CLI was installed with Homebrew, trying to downgrade to 0.140.0 with homebrew didn't result to anything due to lack of formulae, but it's worked with npm as suggested in the Workaround.
But I had to find the working version with the VS Code extension myself: the latest that works for me is 26.5609.30741

li-yazhou · 1 month ago

I can confirm the same regression on an older Intel macOS release:

Codex CLI: 0.141.0 (npm, darwin-x64)
macOS: 13.4.1 (22F82), x86_64
MacBookPro16,1, Intel Core i7
Terminal: Ghostty 1.3.1

I collected 13 identical .ips crash reports. Every crash occurs on
the first tool call with exit 133 / SIGTRAP and the same stack:

v8::base::OS::SetPermissions
→ v8::internal::CodeRange::InitReservation
→ v8::Isolate::New

Version 0.140.0 completes the same prompt normally. This confirms
the regression is not limited to macOS 26.

instylecool · 1 month ago

I can confirm this regression:

Codex CLI: 0.141.0, installed via Homebrew
macOS: 26.5.1 (25F80)
Architecture: Intel x86_64
Hardware: MacBookPro16,1
First functions.exec tool call exits with code 133 / SIGTRAP
Crash stack:

v8::base::OS::SetPermissions
→ v8::internal::CodeRange::InitReservation
→ v8::Isolate::New

A model-only prompt succeeds. The same forced functions.exec → pwd
test succeeds with the Codex.app bundled CLI 0.142.0-alpha.1.

This strongly suggests the regression is fixed or avoided in the
0.142.0-alpha.1 build.

pauleastman · 1 month ago

I tested a narrow local mitigation on an Intel Mac and it appears to avoid the same shell/tool execution failure path on macOS Sequoia 15.5.

Environment:

macOS: macOS 15.5, build 24F74
Architecture: Darwin 24.5.0 x86_64 i386
Branch: fix/macos-x64-rustls-provider-trap
Commit: 86f75ab0c2
Binary tested: codex-rs/target/debug/codex

Mitigation branch:

https://github.com/pauleastman/codex/tree/fix/macos-x64-rustls-provider-trap

Conclusion:

The local macOS x86_64 provider fallback avoids the shell/tool execution crash on my Intel macOS Sequoia 15.5 machine. I ran the codex exec --sandbox read-only "Run the shell command: echo hi. Then report output." repro successfully 4 times with no zsh: trace trap, no SIGTRAP, and no new codex crash report.

Since this issue was reported on macOS 26, this should be treated as related Intel/macOS/x86_64 platform evidence rather than exact same-OS reproduction.

Per the contribution guidelines, I have not opened a PR, but I have a focused branch available and can open one if the maintainers would like to review this approach.

mocaii · 29 days ago

I can independently reproduce the same crash on another Intel macOS 15 system:

Codex CLI: 0.141.0 (@openai/codex installed via npm, darwin-x64)
macOS: 15.7.3 (build 24G419)
Architecture: x86_64
Workspace: an existing Git repository
Trigger: the first functions.exec / shell-tool call after starting an interactive TUI task
Result: the CLI disappears immediately; the requested shell command never starts
Crash time: 2026-06-22 02:50:20 +0800
Exception: EXC_BREAKPOINT (SIGTRAP), termination Trace/BPT trap: 5

The faulting thread has the same stack:

v8::base::OS::SetPermissions
v8::internal::CodeRange::InitReservation
v8::internal::Heap::SetUp
v8::internal::Isolate::Init
v8::Isolate::New

The crash report shows the failure while creating the embedded V8 isolate. This was not an OOM kill (the report records SIGTRAP and the virtual-memory summary does not indicate memory pressure).

The Codex.app bundled CLI on the same machine reports 0.142.0-alpha.6, providing an available newer build for comparison.

Angelo1312 · 27 days ago

Same crash here (filed #29679, closing it as a duplicate of this). Adding two data points that may help narrow the root cause:

1. It only crashes when spawned by VS Code — never from a shell.
Running the exact same bundled binary (<ext>/bin/macos-x86_64/codex app-server) directly over stdio with initialize → thread/new → thread/list (with and without MCP) never crashes (exit 0, and crucially: produces zero new .ips crash reports). Every VS Code launch produces one. The crash report confirms responsibleProc: Code, parentProc: Code Helper (Plugin). So the V8 JIT/executable-memory reservation fails specifically under the process environment VS Code's Electron helper passes to the child on Intel macOS 26 — not from a normal login shell, and MallocNanoZone=0 (injected by VS Code) alone does not reproduce it.

2. Entitlement check supports #28390.
codesign -d --entitlements - on the macos-x86_64/codex binary shows only com.apple.security.cs.allow-jit and not com.apple.security.cs.allow-unsigned-executable-memory. On Intel, V8 typically needs the latter as well.

Workaround that worked for me: downgrading the VS Code extension to 26.602.71036 (bundles CLI 0.137.0-alpha.4). Notably that older binary also lacks the entitlement yet does not crash — so the regression is likely in the V8 version / allocation path in 0.141.0+, consistent with this issue's title (0.140.0 works).

Identical stack: v8::base::OS::SetPermissions → CodeRange::InitReservation → Heap::SetUp → Isolate::Init → v8::Isolate::New, EXC_BREAKPOINT (SIGTRAP). Intel Mac, macOS 26.5.1.

mocaii · 27 days ago

你的邮件已收到，谢谢！

justinwmartin · 27 days ago

Confirming the same regression through the VS Code Remote extension on an older Intel host, including the current stable bundled CLI:

VS Code extension: 26.616.81150 (darwin-x64)
Bundled CLI: codex-cli 0.142.0
Remote host: macOS 13.7.8 (build 22H730), native x86_64
Client: VS Code on an Apple Silicon Mac connected to the Intel Mac via Remote SSH
Tool-free prompt such as "are you there?" succeeds
"Run bootup" crashes on its first custom exec tool call
Repeated crash reports show the identical stack:

v8::base::OS::SetPermissions → CodeRange::InitReservation → Heap::SetUp → Isolate::Init → v8::Isolate::New

VS Code reports SIGTRAP; its displayed "Last CLI error" is only an unrelated bundled-plugin manifest warning
Explicitly setting [features.code_mode] enabled = false, reloading VS Code, and starting a new thread did not prevent the crash. Extension startup logs still advertise thread_tools, and the failed thread transcript confirms the first tool request was custom exec.

Manual execution of the bootup shell command in the VS Code terminal succeeds; summarizing the pasted output without tools also succeeds.

This confirms the regression remains present in stable CLI 0.142.0 when spawned by the VS Code Remote extension and is not limited to newer macOS releases.

vnsmirnv · 20 days ago

Confirming this on a different macOS version, so it's not macOS 26-specific.

codex-cli 0.140.0 works; 0.141.0 / 0.142.3 / 0.142.4 all crash (npm @openai/codex-darwin-x64)
macOS 15.7.7 (24G720), Intel Core i5-8279U (x86_64 native, not Rosetta), 8 GB RAM
Identical signature: EXC_BREAKPOINT / SIGTRAP in v8::base::OS::SetPermissions ← CodeRange::InitReservation ← Heap::SetUp ← Isolate::New (rusty_v8), on a worker thread.

On 0.142.x the crash also fires at TUI startup, while Booting MCP server: codex_apps — i.e. before any user tool call — so the failing V8 Isolate init isn't limited to the first tool invocation.

Ruled out locally: signature valid (codesign --verify OK, Developer ID OpenAI, hardened runtime, com.apple.security.cs.allow-jit present), no quarantine, not Rosetta, no MDM/profiles, Lockdown Mode off, SIP default, ulimits unlimited, no DYLD_* injection. The system Node's own V8 (13.6.x) JITs fine on the same machine. Disabling features (-c features.apps=false, browser_use, in_app_browser, computer_use) does not prevent it.

Pinning to 0.140.0 works for me (0.135.0 too).

SSFSKIM · 20 days ago

Same root cause, adding a data point from codex app-server (JSON-RPC) mode on Intel macOS — plus confirmation the crash is present in the 0.142.x release line, not only 0.141.0.

Environment

Codex CLI: 0.142.3 and 0.142.4 (npm, darwin-x64) — both crash. 0.140.0 does not (downgrading the PATH CLI is a working workaround.)
Platform: Darwin 24.4.0 x86_64 (macOS Sequoia 15.4, Intel)
Model: gpt-5.5 · Plan: Plus
Interface: codex app-server driven programmatically (not the TUI)

Manifestation in app-server mode. On the model's first code-mode exec / exec_command call, the codex app-server process dies on a worker thread with the same EXC_BREAKPOINT (SIGTRAP) inside v8::Isolate::New. Because it's a hard native crash rather than a handled error, the JSON-RPC client gets nothing actionable: stdout just closes (EOF) mid-turn, stderr is empty, there is no error row in logs_2.sqlite, and codex doctor reports the install healthy. So app-server consumers (IDE extensions, custom integrations) observe an opaque "connection closed" partway through a turn, with no signal that the process crashed — the only evidence is the macOS .ips report. Reproduced across ~6 controlled runs, each dying at the identical point (the first exec_command).

Stack from ~/Library/Logs/DiagnosticReports/codex-*.ips, identical to this issue:

EXC_BREAKPOINT (SIGTRAP), Trace/BPT trap: 5   (faulting worker thread)
v8::base::OS::SetPermissions
v8::internal::CodeRange::InitReservation
v8::internal::Heap::SetUp
v8::internal::Isolate::Init
v8::internal::Isolate::InitWithSnapshot
v8::internal::Snapshot::Initialize
v8::Isolate::Initialize
v8::Isolate::New
v8::isolate::Isolate::new::h…   (rust binding)

New data point: an earlier comment reported that 0.142.0-alpha.1 avoided the crash. On the released 0.142.3 and 0.142.4 it is back / still present, so whatever mitigation landed in that alpha did not carry into the 0.142.x stable line. 0.140.0 remains the last version I can confirm works end-to-end on this Intel Mac (a model-only turn succeeds on the broken versions; the crash is specifically the first V8-backed exec call, matching every report above).

Happy to attach a full .ips if it would help.

cconger contributor · 19 days ago

Yes @SSFSKIM can you please share your ips. Feel free to redact usernames and paths from it. If you want to email its my username here at openai.com

lzwmt · 12 days ago

Confirming the same regression on macOS 12 Intel, with a stable version boundary and newer CLI versions.

Environment

macOS: 12.7.6 (21H1320)
Architecture: native x86_64 Intel
Terminal: Kaku (kaku-gui)
Installation: npm @openai/codex, darwin-x64

Version matrix

0.140.0: works normally on the same machine and configuration
0.141.0: crashes
0.142.5: crashes
0.143.0: crashes

The failure reproduces even when starting with:

codex --disable unified_exec --disable code_mode

Crash signature

Every failing run creates a macOS .ips report with:

EXC_BREAKPOINT (SIGTRAP)
Trace/BPT trap: 5

v8::base::OS::SetPermissions(void*, unsigned long, v8::base::OS::MemoryPermission)
v8::internal::CodeRange::InitReservation(v8::PageAllocator*, unsigned long, bool)
v8::internal::Heap::SetUp(v8::internal::LocalHeap*)
v8::internal::Isolate::Init(...)
v8::internal::Isolate::InitWithSnapshot(...)
v8::internal::Snapshot::Initialize(...)
v8::Isolate::Initialize(...)
v8::Isolate::New(...)
v8::isolate::Isolate::new(...)

For example, the 0.142.5 process started at 2026-07-08 22:44:32 +0800 and crashed about 40 seconds later. The same stack was captured repeatedly on 0.141.0+.

The accompanying Node crash report is only the npm launcher forwarding the child process signal via node::Kill; the native Codex child is the process that first crashes in v8::Isolate::New.

This confirms the regression also affects the oldest officially supported macOS generation, not only macOS 13/15/26. Pinning @openai/codex@0.140.0 is a reliable workaround on this host.

I can provide a redacted full .ips report if useful.

cconger contributor · 12 days ago

I believe this should be resolved by this fix here: https://github.com/openai/codex/pull/30953

Which should be included in https://github.com/openai/codex/releases/tag/rust-v0.143.0-alpha.39

If you are able to validate that would be helpful.