Note / prior art: This is very likely the same root cause as #27358 (and #27422, which was closed as a duplicate of it). I'm filing a separate, narrowly-scoped report because the #27358 opening post attributes the crash to an invalid/ignored entitlements blob, whereas on my install the signature is fully valid and the entitlement is simply absent — the distinction only surfaces in that issue's comments. Happy for a maintainer to dup this if preferred; cross-referencing for searchability.
What version of Codex CLI is running?
codex-cli 0.139.0 (npm, @openai/codex → @openai/codex-darwin-x64 vendor binary)
What subscription do you have?
ChatGPT (auth mode chatgpt)
Which model were you using?
gpt-5.5 (tool_mode: "code_mode_only" in the model catalogue, so the first tool call of any session spawns the V8 runtime)
What platform is your computer?
- macOS 15.7.7 (build 24G720)
- Darwin 24.6.0, x86_64
- Intel Core i7-8750H, MacBookPro15,1 (no Rosetta)
What terminal emulator and version are you using (if applicable)?
iTerm2 3.7.20260602-nightly
Codex doctor report
codexVersion: 0.139.0
overallStatus: warning
model: gpt-5.5 (provider: openai)
CODEX_HOME: ~/.codex
auth storage mode: File (chatgpt)
What issue are you seeing?
The CLI crashes with Trace/BPT trap: 5 (SIGTRAP) the moment the model executes its first tool call. The macOS crash report shows EXC_BREAKPOINT (SIGTRAP) with a faulting thread inside V8 isolate creation:
Exception Type: EXC_BREAKPOINT (SIGTRAP)
Termination Reason: Trace/BPT trap: 5
v8::base::OS::SetPermissions(void*, unsigned long, v8::base::OS::MemoryPermission)
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::... ← rusty_v8 binding
std::sys::backtrace::__rust_begin_short_backtrace
Reproduced 4/4 times, identical stack each time.
Root cause (confirmed locally): the darwin-x64 vendor binary is signed with Hardened Runtime enabled but ships entitlements containing only com.apple.security.cs.allow-jit. On Intel macOS, V8's code-range setup maps JIT pages and then flips them to executable via mprotect(PROT_READ|PROT_EXEC), which under Hardened Runtime requires com.apple.security.cs.allow-unsigned-executable-memory. That entitlement is absent, the kernel denies the call, and V8's internal CHECK aborts → SIGTRAP.
The signature itself is valid — this is not the "invalid entitlements blob" case from #27358's OP:
$ codesign -dvvv .../@openai/codex-darwin-x64/vendor/x86_64-apple-darwin/bin/codex
Identifier=codex
CodeDirectory ... flags=0x10000(runtime)
Authority=Developer ID Application: OpenAI OpCo, LLC (2DC432GLL2)
TeamIdentifier=2DC432GLL2
$ codesign -d --entitlements - --xml .../bin/codex
<plist><dict>
<key>com.apple.security.cs.allow-jit</key><true/>
</dict></plist>
# com.apple.security.cs.allow-unsigned-executable-memory is missing
What steps can reproduce the bug?
On an Intel (x86_64) Mac under Hardened Runtime, with gpt-5.5 selected:
codex exec --skip-git-repo-check "Use your exec tool to run: echo hello"
The TUI/exec starts, and the process dies with trace trap codex (exit 133) as soon as the first tool call spawns the V8 runtime.
What is the expected behavior?
The tool call runs and the session continues — no crash. The darwin-x64 (and any x86_64) binary should be signed with com.apple.security.cs.allow-unsigned-executable-memory in addition to allow-jit, matching the entitlement V8 requires for RWX JIT memory on Intel macOS under Hardened Runtime.
Additional information
What version of Codex CLI is running?
codex-cli 0.139.0(npm,@openai/codex→@openai/codex-darwin-x64vendor binary)What subscription do you have?
ChatGPT (auth mode
chatgpt)Which model were you using?
gpt-5.5(tool_mode: "code_mode_only"in the model catalogue, so the first tool call of any session spawns the V8 runtime)What platform is your computer?
What terminal emulator and version are you using (if applicable)?
iTerm2 3.7.20260602-nightly
Codex doctor report
What issue are you seeing?
The CLI crashes with
Trace/BPT trap: 5(SIGTRAP) the moment the model executes its first tool call. The macOS crash report showsEXC_BREAKPOINT (SIGTRAP)with a faulting thread inside V8 isolate creation:Reproduced 4/4 times, identical stack each time.
Root cause (confirmed locally): the
darwin-x64vendor binary is signed with Hardened Runtime enabled but ships entitlements containing onlycom.apple.security.cs.allow-jit. On Intel macOS, V8's code-range setup maps JIT pages and then flips them to executable viamprotect(PROT_READ|PROT_EXEC), which under Hardened Runtime requirescom.apple.security.cs.allow-unsigned-executable-memory. That entitlement is absent, the kernel denies the call, and V8's internalCHECKaborts →SIGTRAP.The signature itself is valid — this is not the "invalid entitlements blob" case from #27358's OP:
What steps can reproduce the bug?
On an Intel (x86_64) Mac under Hardened Runtime, with
gpt-5.5selected:The TUI/exec starts, and the process dies with
trace trap codex(exit 133) as soon as the first tool call spawns the V8 runtime.What is the expected behavior?
The tool call runs and the session continues — no crash. The
darwin-x64(and any x86_64) binary should be signed withcom.apple.security.cs.allow-unsigned-executable-memoryin addition toallow-jit, matching the entitlement V8 requires for RWX JIT memory on Intel macOS under Hardened Runtime.Additional information
pthread_jit_write_protect_npW^X toggle, whichallow-jitalone satisfies — which is likely why this slips past ARM-only CI.