CLI 0.139.0 (npm, x86_64): SIGTRAP in v8::base::OS::SetPermissions on first tool call — darwin-x64 binary missing allow-unsigned-executable-memory entitlement

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

• Same faulting stack and root cause reported in #27358; #27422 (Intel MacBookPro15,1 / macOS 15.7.7 / 0.139.0) was closed as a duplicate of it.
• A one-line entitlements fix has already been proposed in the #27358 thread and verified by multiple reporters across npm, Homebrew, and standalone channels.
• Apple Silicon is unaffected because V8 there uses the pthread_jit_write_protect_np W^X toggle, which allow-jit alone satisfies — which is likely why this slips past ARM-only CI.