›_ Codex Issues
Codex Issues / #30306

codex-cli 0.142.3 still crashes with Trace/BPT trap: 5 (SIGTRAP) on tool calls (web_search + shell) on Intel macOS — regression of #29000

Open 💬 7 comments Opened Jun 26, 2026 by leonaburime-ucla
💡 Likely answer: A maintainer (github-actions[bot], contributor) responded on this thread — see the highlighted reply below.

Summary

On Intel (x86_64) macOS, codex-cli 0.142.3 still crashes with a native Trace/BPT trap: 5 (SIGTRAP) the moment it invokes a tool — both web_search and local shell/file reads abort with no output and the conversation reports "Conversation interrupted."

This appears to be the same crash as #29000 (closed as completed on 2026-06-23) and #28090 (open). #29000 was marked fixed, but it is still reproducing on 0.142.0–0.142.3 per recent comments there. Filing fresh so the regression on the latest version is visible.

What version of Codex CLI is running?

0.142.3

Which model were you using?

gpt-5.5

What platform is your computer?

macOS 13.7.5 (build 22H527), x86_64 (Intel)

Steps to reproduce

  1. Start codex in a repository (a SessionStart hook was active; working directory path contains a space: .../Wordpress for Apps).
  2. Ask Codex to perform a web search.
  3. Codex first attempts a local file read / shell command; the command aborts and the terminal prints:

``
Trace/BPT trap: 5
``

  1. Resume the session and ask Codex to invoke web search directly (no shell command).
  2. The search produces no output; the conversation reports:

``
Conversation interrupted - tell the model what to do differently.
Something went wrong? Hit /feedback to report the issue.
``

Expected behavior

Tool calls (web_search, shell, file read) return results or a recoverable error without terminating the process.

Actual behavior

Any tool invocation aborts without output; at least one invocation produced a native Trace/BPT trap: 5 (SIGTRAP). web_search is effectively unusable in the session.

Additional observations

  • Both local command execution and web search are affected, which points at the shared tool runner / JIT path rather than web_search alone.
  • Consistent with #29000 / #28090 root-cause discussion: V8 JIT SetPermissions failing under macOS Hardened Runtime (invalid/ignored entitlements blob).
  • No usage-limit reset was consumed.
  • Date observed: 2026-06-26.

Environment

  • Codex version: codex-cli 0.142.3
  • macOS: 13.7.5 (22H527)
  • Architecture: x86_64 (Intel)
  • Shell: bash
  • Terminal: Terminal.app (macOS default)

Related

  • #29000 (closed as completed, but still reproduces on 0.142.x)
  • #28090 (open)

View original on GitHub ↗

7 Comments

github-actions[bot] contributor · 24 days ago

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

  • #30300
  • #29000
  • #29047
  • #29414
  • #29136

Powered by Codex Action

Karabaaa · 21 days ago

Still reproducible with Codex CLI 0.142.4 and the VS Code extension.

Environment:

  • macOS 15.7.4 (24G517)
  • Intel MacBookPro16,1 (x86_64)
  • Codex CLI 0.142.4
  • VS Code extension 26.623.61825

The app-server exits with SIGTRAP while initializing V8:

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

The issue still reproduces after:

  • Reinstalling Codex
  • Removing the template-creator plugin
  • Setting features.plugins = false
  • Pointing chatgpt.cliExecutable to the standalone 0.142.4 binary
  • Rebooting macOS

codesign --verify --strict also reports an invalid signature for both the standalone and VS Code bundled Intel binaries.

I am attaching a sanitized macOS crash report and VS Code Codex log.

codex-crash-2026-06-29-sanitized.zip
Codex.sanitized.log

charlieargue · 21 days ago

I’m seeing the same issue on @openai/codex@0.142.4 installed via Volta/npm on Intel macOS.

Environment:

  • Codex CLI broken version: 0.142.4
  • Working rollback version: 0.137.0
  • macOS: 14.8.4 (23J319)
  • Hardware: Intel MacBookPro16,1 / x86_64
  • Shell/terminal: zsh in iTerm2
  • Node: v24.14.0
  • Install path: /Users/karlgolka/.volta/tools/image/packages/@openai/codex/...

Failure mode:

  • 0.142.4 crashes when a turn attempts a tool/custom tool call.
  • Reverting to 0.137.0 restores normal operation.
  • The crash is not repo-specific; it occurred while reading a local skill file before meaningful repo work.

Crash reports observed:

  • ~/Library/Logs/DiagnosticReports/codex-2026-06-29-125709.ips
  • ~/Library/Logs/DiagnosticReports/codex-2026-06-29-130301.000.ips
  • ~/Library/Logs/DiagnosticReports/codex-2026-06-29-130807.000.ips
  • ~/Library/Logs/DiagnosticReports/codex-2026-06-29-130939.ips
  • ~/Library/Logs/DiagnosticReports/codex-2026-06-29-131217.ips

Crash signature:

```
Exception: EXC_BREAKPOINT / SIGTRAP
Termination: Trace/BPT trap: 5

codex v8::base::OS::SetPermissions
codex v8::internal::CodeRange::InitReservation
codex v8::internal::Heap::SetUp
codex v8::internal::Isolate::Init
codex v8::internal::Isolate::InitWithSnapshot
codex v8::internal::Snapshot::Initialize
codex v8::Isolate::Initialize
codex v8::Isolate::New
codex v8::isolate::Isolate::new
```

Related secondary symptom:

``text
codex_core::util: Custom tool call output is missing for call id: ...
``

That appears to be fallout after the native process dies mid-tool-call: the session has a recorded tool call but no corresponding output.

This looks consistent with the V8/JIT/hardened-runtime SIGTRAP already discussed here. Adding this data point because it reproduces on 0.142.4 and on macOS 14.8.4, not only macOS 15/26.

charlieargue · 21 days ago

FYI - in meantime, 👍 reverting to 137 solved the issue for now ...

seth-reeise · 14 days ago

Can we please get this fixed?

I’m seeing what appears to be the same issue on my Intel Mac server.

Environment:

  • Machine: Mid-2012 MacBook Pro, MacBookPro9,1
  • CPU: Intel Core i7 quad-core 2.3 GHz
  • RAM: 16 GB
  • macOS: Catalina 10.15.7
  • Build: 19H2026
  • Architecture: x86_64 / Intel
  • Shell: bash
  • Usage: connected over SSH, usually running Codex inside tmux
  • Install method: npm/global Codex CLI install
  • Codex CLI version 0.142.0 line

Behavior:

When Codex tries to invoke tools, especially shell commands/file reads, the session crashes/interrup​ts instead of returning tool output. I have seen the native macOS error:

Trace/BPT trap: 5

After that, Codex reports the conversation as interrupted / failed rather than showing the result of the tool call.

This is happening on an older Intel Mac server, not Apple Silicon. It sounds consistent with the Intel macOS SIGTRAP/tool-runner issue described here and in the related issues. The main trigger appears to be tool execution.

Tuttotorna · 13 days ago

This looks like a shared native tool-runner support boundary, not only a web_search or shell-specific crash.

The runtime should separate:

tool call selected
≠
the shared native tool runner is executable in the current platform/runtime context

In the report, multiple tool paths fail through the same native failure mode:

  • shell / file read aborts with Trace/BPT trap: 5
  • web_search produces no output
  • the conversation reports "Conversation interrupted"
  • both local and remote/search tool paths appear affected
  • the environment is Intel macOS with codex-cli 0.142.3

That points to a common tool-runner / runtime execution layer rather than the individual tool implementation.

Minimal invariant:

ToolDispatchSupported(tool, env)
requires:

  • tool schema valid
  • tool selected
  • shared runner loadable
  • native runtime/JIT permissions valid
  • platform entitlement state valid
  • tool subprocess/task starts successfully
  • terminal outcome observable

Failure shape:

model requests a tool
+
Codex enters shared tool-runner path
+
native runtime traps before tool output
+
conversation becomes interrupted
=>
the tool transition has no supported terminal outcome

A useful local classifier:

def classify_tool_runner_support(env):
required = {
"shared_runner_loadable",
"native_runtime_permissions_valid",
"platform_entitlements_valid",
"tool_process_start_supported",
"terminal_outcome_supported",
}

supported = set(env.get("supported", []))
missing = required - supported

if missing:
return {
"decision": "block_tool_dispatch",
"reason": "shared_tool_runner_not_supported",
"missing_support": sorted(missing),
"platform": env.get("platform"),
"arch": env.get("arch"),
"codex_version": env.get("codex_version"),
}

return {
"decision": "dispatch_tool_call",
"missing_support": [],
}

Regression cases:

  1. Intel macOS + shared runner cannot start because native runtime permissions fail

=> local shared_tool_runner_not_supported diagnostic

  1. shell tool and web_search both fail through the same SIGTRAP path

=> classify as shared runner failure, not two independent tool failures

  1. tool runner traps before producing output

=> terminal outcome = native_runner_trap, not generic Conversation interrupted

  1. same Codex version on supported architecture/runtime

=> tool calls return output or structured tool error

  1. regression from a previously closed fix

=> startup preflight detects unsupported native runner before the first tool call

The key boundary is:

a tool call is dispatchable only if the common execution layer for tools is supported on that platform.

If the shared runner cannot start because of native runtime / entitlement / JIT permission failure, Codex should fail locally with a named diagnostic such as shared_tool_runner_not_supported or native_runner_trap instead of collapsing the session into a generic conversation interruption.

charlieargue · 6 days ago

Any update on this issue? I'm still in a 0.137.0 holding pattern until this is resolved and I can safely upgrade. Appreciate any info, 🙏 big 👍 Thanks!