Trace/BPT trap: 5 (SIGTRAP) on macOS 15
What version of Codex CLI is running?
codex-cli 0.139.0
What subscription do you have?
Chatgpt Plus
Which model were you using?
gpt-5.5
What platform is your computer?
Darwin 24.6.0 x86_64 i386
What terminal emulator and version are you using (if applicable)?
iTerm2
Codex doctor report
not available
What issue are you seeing?
Codex cli crashes with 'Trace/BPT trap: 5 (SIGTRAP)' when attempting to execute tools (shell, filesystem) etc. The crash was diagnosed and fixed with Gemini, revealing an issue when using codex in macOS 15.7.7. The generated crash report and fix is attached below
What steps can reproduce the bug?
Codex CLI Crash Report: Trace/BPT trap: 5 (SIGTRAP) on macOS 15
Summary
The Codex CLI (v0.139.0) crashes with a Trace/BPT trap: 5 (SIGTRAP) on macOS 15.7.7 when attempting to execute tools (shell, filesystem, etc.). The crash occurs during V8 initialization, specifically when the runtime attempts to set permissions for JIT-allocated memory.
Environment
- Codex Version: 0.139.0
- OS: macOS 15.7.7 (Build 24G720)
- Architecture: x86_64
- Binary Path:
~/.codex/packages/standalone/releases/0.139.0-x86_64-apple-darwin/bin/codex
Reproduction Steps
- Install Codex CLI v0.139.0 on macOS 15 (x86_64).
- Run any command that triggers tool usage (e.g.,
codex exec "ls"). - Observe the crash:
/bin/bash: line 2: <pid> Trace/BPT trap: 5.
Diagnostic Investigation
1. Crash Log Analysis
Analysis of the macOS IPS crash reports (~/Library/Logs/DiagnosticReports/codex-*.ips) revealed the following:
- Exception Type:
EXC_BREAKPOINT (SIGTRAP) - Faulting Thread Stack Trace:
```
0 libsystem_kernel.dylib __ulock_wait + 10
1 libsystem_pthread.dylib _pthread_join + 348
...
triggered: true, id: <thread_id>, name: "V8 DefaultWorker"
frames:
0 codex v8::base::OS::SetPermissions(void*, unsigned long, v8::base::OS::MemoryPermission) + 231
1 codex v8::internal::CodeRange::InitReservation(v8::PageAllocator*, unsigned long, bool) + 587
2 codex v8::internal::Heap::SetUp(v8::internal::LocalHeap*) + 399
...
SetPermissions` fails. On macOS, this is often due to Hardened Runtime restrictions on JIT memory allocation.
The crash happens when V8's
2. Entitlements Check
Checking the original entitlements with codesign -d --entitlements :- <path> showed:
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "https://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>com.apple.security.cs.allow-jit</key>
<true/>
</dict>
</plist>
While allow-jit was present, it appears insufficient on macOS 15 for the standalone binary's specific memory mapping requirements.
Root Cause
The x86_64 standalone binary for macOS fails to initialize the V8 engine because it lacks the necessary entitlements to allocate and manage unsigned executable memory required for JIT compilation under the Hardened Runtime on macOS 15.
Solution / Workaround
Re-signing the binary with expanded entitlements resolves the crash.
Steps to Fix Locally:
- Create an
entitlements.plistfile:
``xml``
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>com.apple.security.cs.allow-jit</key>
<true/>
<key>com.apple.security.cs.allow-unsigned-executable-memory</key>
<true/>
<key>com.apple.security.cs.disable-library-validation</key>
<true/>
</dict>
</plist>
- Re-sign the binary:
``bash``
codesign --force --sign - --entitlements entitlements.plist ~/.codex/packages/standalone/releases/0.139.0-x86_64-apple-darwin/bin/codex
Recommendations for GitHub Fix
The build pipeline for the macOS x86_64 (and potentially aarch64) standalone releases should be updated to include the following entitlements:
com.apple.security.cs.allow-jitcom.apple.security.cs.allow-unsigned-executable-memorycom.apple.security.cs.disable-library-validation(especially if loading external MCP servers or plugins as dynamic libraries).
What is the expected behavior?
_No response_
Additional information
_No response_
This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗