macOS Intel: Codex CLI 0.142.4 crashes with SIGTRAP when using GPT-5.5, GPT-5.4 works normally

What version of Codex CLI is running?

0.142.4

What subscription do you have?

plus

Which model were you using?

_No response_

What platform is your computer?

_No response_

What terminal emulator and version are you using (if applicable)?

_No response_

Codex doctor report

What issue are you seeing?

Environment

• Codex CLI: 0.142.4
• Installation: npm
• Node.js: v22.22.1
• macOS: 14.7.4 Sonoma
• Hardware: Intel MacBook Pro (MacBookPro16,1)
• Architecture: x86_64

Config

config.toml

model = "gpt-5.5"
model_reasoning_effort = "medium"

No custom base_url.
No custom model_provider.
Using official ChatGPT login.

Problem

When using GPT-5.5, Codex consistently crashes after entering the "Working..." stage.

Example:

• Working (4s • esc to interrupt)

zsh: trace trap  codex

Changing only the model to GPT-5.4 makes the exact same project and prompt work normally.

Expected behavior

Codex should continue processing the request.

Actual behavior

The Codex process exits with SIGTRAP.

Shell output:

zsh: trace trap codex

Crash report

The crash report shows:

Exception Type: EXC_BREAKPOINT (SIGTRAP)
CPU Type: X86-64

The stack indicates the crash occurs during V8 initialization:

v8::base::OS::SetPermissions(...)
v8::internal::CodeRange::InitReservation(...)
v8::internal::Heap::SetUp(...)
v8::internal::Isolate::Init(...)
v8::Isolate::Initialize(...)
v8::Isolate::New(...)

This suggests the crash happens during V8 isolate initialization rather than during network communication.

Reproduction

1. Install Codex CLI 0.142.4
2. Login with ChatGPT account
3. Set

model = "gpt-5.5"

1. Open any project
2. Ask Codex to analyze the project
3. Wait until "Working..."
4. Codex exits with SIGTRAP

Changing only the model to GPT-5.4 avoids the crash.

Additional observations

• GPT-5.4 works correctly.
• GPT-5.5 crashes consistently.
• Same machine.
• Same project.
• Same configuration except model.
• No custom API endpoint.

What steps can reproduce the bug?

Execute the command

What is the expected behavior?

_No response_

Additional information

_No response_