Trace/BPT trap: 5 (SIGTRAP) on macOS 15

Open 💬 2 comments Opened Jun 13, 2026 by bryanwuyw

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

  1. Install Codex CLI v0.139.0 on macOS 15 (x86_64).
  2. Run any command that triggers tool usage (e.g., codex exec "ls").
  3. 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
...
`
The crash happens when V8's
SetPermissions` fails. On macOS, this is often due to Hardened Runtime restrictions on JIT memory allocation.

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:

  1. Create an entitlements.plist file:

``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>
``

  1. 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-jit
  • com.apple.security.cs.allow-unsigned-executable-memory
  • com.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_

View original on GitHub ↗

This issue has 2 comments on GitHub. Read the full discussion on GitHub ↗