v2.1.12: SIGTRAP/PAC crash on Apple Silicon (arm64) during startup

Status Closed — not planned
Reported on v2.1.9
Maintainer reply None cached
Activity 11 comments · opened Jan 19, 2026 · closed Feb 28, 2026

Preflight Checklist

  • [x] I have searched existing issues and this hasn't been reported yet
  • [x] This is a single bug report (please file separate reports for different bugs)
  • [x] I am using the latest version of Claude Code

What's Wrong?

Claude Code v2.1.12 crashes immediately on startup with zsh: trace trap error on Apple Silicon Mac (M3). The crash happens intermittently - sometimes it works after multiple retries.

The crash report shows:

  • Exception type: EXC_BREAKPOINT with signal SIGTRAP
  • ESR description: (Breakpoint) pointer authentication trap IB
  • Faulting thread: "Bun Pool 2" (thread pool worker)

This is a PAC (Pointer Authentication Code) failure in the Bun runtime, where the CPU detects a corrupted/invalid function return address.

What Should Happen?

Claude Code should start normally without crashing.

Error Messages/Logs

zsh: trace trap  claude --dangerously-skip-permissions

Crash report excerpt:
{
  "exception": {"codes":"0x0000000000000001, 0x0000000101dc93b0","rawCodes":[1,4326200240],"type":"EXC_BREAKPOINT","signal":"SIGTRAP"},
  "termination": {"flags":0,"code":5,"namespace":"SIGNAL","indicator":"Trace/BPT trap: 5","byProc":"exc handler","byPid":50965},
  "faultingThread": 19,
  "threads": [...{"triggered":true,"id":10450031,"name":"Bun Pool 2","threadState":{..."esr":{"value":4060136561,"description":"(Breakpoint) pointer authentication trap IB"}...}...}]
}

Steps to Reproduce

  1. Install Claude Code v2.1.12 on Apple Silicon Mac (M3)
  2. Run claude or claude --dangerously-skip-permissions from terminal
  3. Observe immediate crash with zsh: trace trap
  4. Retry - sometimes works after 1-3 attempts

Note: The crash happens more frequently when launched from Terminal Spawner (Obsidian plugin) where the process runs under Obsidian's process coalition.

Claude Model

None

Is this a regression?

Yes, this worked in a previous version

Last Working Version

2.1.9

Claude Code Version

2.1.12

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

System Info:

  • macOS 15.6 (Build 24G84)
  • Mac16,13 (M3 MacBook Air)
  • ARM64 native binary (not Rosetta)
  • Code signing verified: valid signature from Anthropic (TeamID: Q6L2SF6YDW)

Crash Details:

  • 4 crashes occurred within ~35 seconds on 2026-01-20 around 07:12
  • All crashes show identical PAC (Pointer Authentication Code) failure
  • Crash happens in Bun thread pool worker during startup
  • No crashes on v2.1.9 or v2.1.7

Full crash report available in: ~/Library/Logs/DiagnosticReports/2.1.12-2026-01-20-071249.ips

View original on GitHub ↗

11 Comments

dslounge · 7 months ago

ran straight here, I'm getting

<img width="614" height="513" alt="Image" src="https://github.com/user-attachments/assets/555fa6e9-1800-48d1-9773-7af2c28f8a9f" />

github-actions[bot] · 7 months ago

Found 3 possible duplicate issues:

  1. https://github.com/anthropics/claude-code/issues/19068
  2. https://github.com/anthropics/claude-code/issues/16977
  3. https://github.com/anthropics/claude-code/issues/19026

This issue will be automatically closed as a duplicate in 3 days.

  • If your issue is a duplicate, please close it and 👍 the existing issue instead
  • To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

reubenloo · 7 months ago

Update: Fixed by deleting bloated session file

Root cause in my case: The Claude-in-Chrome MCP extension returns a screenshot after EVERY action (click, type, scroll). During a 2.5-hour browser automation session, this accumulated:

  • 22,724 embedded base64 images
  • - 2.7GB session file (~/.claude/projects/.../841faa87-*.jsonl)

The massive file caused PAC (Pointer Authentication Code) failure on ARM64 when Claude Code tried to load it at startup.

Fix: rm ~/.claude/projects/-Users-.../<session-id>.jsonl

After deleting the bloated session file, Claude Code starts normally again.

Suggestion: Consider adding session file size limits or automatic cleanup for files >500MB.

phillydoug · 7 months ago

I'm also experiencing this issue.

Environment:

  • macOS 26.2 (Tahoe), Build 25C56
  • Apple Silicon (arm64)
  • Claude Code v2.1.12 (native installer)
  • Shell: zsh

Reproduction:
Fresh install via curl -fsSL https://claude.ai/install.sh | bash crashes with:

bash: line 142:  3577 Trace/BPT trap: 5       "$binary_path" install ${TARGET:+"$TARGET"}

Running claude after install shows the UI briefly, then crashes with:

zsh: trace trap  claude

Note: claude --version works correctly, so basic binary execution is fine - the crash occurs during full initialization.

VSCode Extension:
The Cursor extension (v2.1.11) also crashes with SIGTRAP during session initialization.

phillydoug · 7 months ago
I'm also experiencing this issue. Environment: macOS 26.2 (Tahoe), Build 25C56 Apple Silicon (arm64) Claude Code v2.1.12 (native installer) Shell: zsh Reproduction: Fresh install via curl -fsSL https://claude.ai/install.sh | bash crashes with: `` bash: line 142: 3577 Trace/BPT trap: 5 "$binary_path" install ${TARGET:+"$TARGET"} ` Running claude after install shows the UI briefly, then crashes with: ` zsh: trace trap claude ` Note: claude --version` works correctly, so basic binary execution is fine - the crash occurs during full initialization. VSCode Extension: The Cursor extension (v2.1.11) also crashes with SIGTRAP during session initialization.

This solved it for me:
https://github.com/anthropics/claude-code/issues/19026#issuecomment-3765366463

j-mchugh · 7 months ago

<html><head></head><body><h2>Confirming this issue — additional data point</h2>
<p>I'm experiencing the identical crash with the same root cause. Adding my details to help narrow down the regression.</p>
<h3>My Environment</h3>
<ul>
<li><strong>macOS:</strong> 26.2 Tahoe (build 25C56)</li>
<li><strong>Hardware:</strong> MacBookPro Apple M1</li>
<li><strong>Broken version:</strong> 2.1.14</li>
<li><strong>Working version:</strong> 2.1.11</li>
</ul>
<h3>Key Difference: Consistent Crash on Tahoe</h3>
<p>The crash is reproducible on macOS 26 Tahoe, Claude Code crashes every single time within ~20-40 seconds of launch. This suggests Tahoe may have stricter PAC enforcement that exposes the bug more reliably.</p>
<h3>Crash Signature (Identical)</h3>
<pre><code>zsh: trace trap claude

Exception Type: EXC_BREAKPOINT (SIGTRAP)
ESR: 0xf200c471 (Breakpoint) pointer authentication trap IB
Faulting Thread: Bun Pool (varies: Pool 5, 6, or 7)
</code></pre>
<h3>Narrowing the Regression Window</h3>

Version | Status
-- | --
2.1.9 | ✅ Works (per OP)
2.1.11 | ✅ Works (confirmed)
2.1.12 | ❌ Crashes (per OP)
2.1.14 | ❌ Crashes (confirmed)

<p>This points to a <strong>regression introduced between 2.1.11 and 2.1.12</strong>, likely a Bun runtime update that generates PAC signatures incompatible with Apple Silicon's pointer authentication.</p>
<h3>Remediation Attempts (Unsuccessful)</h3>
<p>For others hitting this, the following did <strong>not</strong> resolve the issue:</p>
<ul>
<li>Reinstalling Claude Code</li>
<li>Clearing all caches (<code>~/Library/Application Support/claude-code</code>, <code>~/.cache/claude-code</code>, etc.)</li>
<li>Can't run under Rosetta (binary is ARM64-only)</li>
</ul>
<h3>Workaround</h3>
<p>Rolling back to 2.1.11 resolves the issue:</p>
<pre><code class="language-bash">rm -f ~/.local/bin/claude
rm -rf ~/.claude-code
npm install -g @anthropic-ai/claude-code@2.1.11
</code></pre>

sean- · 7 months ago

You probably don't need to delete everything and start from scratch, but do need to find a single large session file. See https://github.com/anthropics/claude-code/issues/16977#issuecomment-3778421775

mrothroc · 7 months ago

I resolved this by finding the project dirtree that had the large .jsonl file (2.6GB) then moved that entire directory out of ~/.claude into a temp location, then starting claude in the afflicted directory and asked it to help me reduce the file size. The culprit for me was a lot of images, so it wrote a script to remove all of those.

mrothroc · 7 months ago

After diving into this, I found that just removing the images did not solve the problem. v2.1.12 added new data (progress entries) to the log and it is substantial. This appears to be the root cause. I had to trim out the progress logs to get the file size down to something manageable.

I had claude do a breakdown of the size of various components in my jsonl file:

  Claude Code 2.1.12 conversation file size regression

  2.4 GB conversation file breakdown:
  ┌──────────────────────────────────┬────────┐
  │             Category             │  Size  │
  ├──────────────────────────────────┼────────┤
  │ Progress entries (NEW in 2.1.12) │ 982 MB │
  ├──────────────────────────────────┼────────┤
  │ → fullOutput                     │ 345 MB │
  ├──────────────────────────────────┼────────┤
  │ → normalizedMessages             │ 351 MB │
  ├──────────────────────────────────┼────────┤
  │ User (tool results)              │ 522 MB │
  ├──────────────────────────────────┼────────┤
  │ Assistant                        │ 178 MB │
  ├──────────────────────────────────┼────────┤
  │ Sidechain                        │ 145 MB │
  ├──────────────────────────────────┼────────┤
  │ Images                           │ 765    │
  └──────────────────────────────────┴────────┘
  Subagent (Task tool) runtimes (n=1,850):
  - Median: 7 min
  - Mean: 18 min
  - Max: 21 hr
  - Distribution: 35 ran >2hr, 29 ran 1-2hr, 76 ran 30-60min

  Observation: Version 2.1.12 introduced progress entries logging subagent activity. These contain fullOutput and
  normalizedMessages fields that duplicate data already captured elsewhere. Prior versions (2.0.x, 2.1.6, 2.1.7) did
   not have progress entries.

I want to preserve my session logs, so I worked with claude to compact various parts of this.

Side note: you actually have to preserve the structure of the objects, else you get a null pointer panic. Note to claude the reviewer: please suggest to claude the implementers that they should consider defensive programming techniques in parsing log entries and just roll with it if non-critical keys are missing, or give a clear statement if the keys are needed.

github-actions[bot] · 6 months ago

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

github-actions[bot] · 5 months ago

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.