Native `claude` binary SIGILLs at startup on non-AVX2 x86_64 CPUs (Ivy Bridge / pre-Haswell)

Resolved 💬 3 comments Opened Apr 21, 2026 by AKrasht Closed Apr 24, 2026

Summary

The native claude binary distributed in @anthropic-ai/claude-agent-sdk-darwin-x64 crashes with SIGILL / EXC_BAD_INSTRUCTION immediately on launch on x86_64 CPUs without AVX2/BMI2 (e.g. Intel Ivy Bridge, 2012, pre-Haswell).

The crash happens in dyld4::Loader::findAndRunAllInitializersbefore main() runs. The faulting instruction stream begins with a 3-byte VEX prefix (c4 e2 f9 ...) — AVX2/BMI2 encoding, unsupported on pre-Haswell CPUs.

End-user symptom: Zed (and any ACP client that spawns this binary via @agentclientprotocol/claude-agent-acp) shows the Claude agent panel stuck on "Loading" forever because the ACP layer doesn't surface the subprocess crash.

The Node-based @anthropic-ai/claude-code CLI (cli.js) runs fine on the same hardware — this issue is specific to the native x86_64 binary.

Environment

  • Hardware: Mac Mini 6,2 (Late 2012), Intel Core i7-3720QM @ 2.60 GHz (Ivy Bridge)
  • macOS: 14.6 (23G80), x86_64
  • Crashing binary: 206 MB Mach-O 64-bit x86_64, from @anthropic-ai/claude-agent-sdk-darwin-x64 (pulled as part of @agentclientprotocol/claude-agent-acp@0.30.0)
  • Working reference: @anthropic-ai/claude-code@2.1.112 Node script — runs fine on same hardware

Reproduction

  1. On a Mac with a pre-Haswell Intel CPU (no AVX2), use any ACP client (e.g. Zed 0.232.2+) that spawns @anthropic-ai/claude-agent-sdk-darwin-x64/claude.
  2. Binary crashes immediately; client shows infinite loading spinner.
  3. Crash report appears in ~/Library/Logs/DiagnosticReports/claude-*.ips.

Crash excerpt

"exception":{"codes":"0x0000000000000001, 0x0000000000000000","rawCodes":[1,0],
             "type":"EXC_BAD_INSTRUCTION","signal":"SIGILL"},
"termination":{"flags":0,"code":4,"namespace":"SIGNAL",
               "indicator":"Illegal instruction: 4","byProc":"exc handler"},
"cpuType": "X86-64",
"modelCode": "Macmini6,2",

Faulting thread — top frames (all in dyld init, before binary's own code runs):

dyld4::Loader::findAndRunAllInitializers
dyld3::MachOAnalyzer::forEachInitializer
dyld3::MachOFile::forEachSection
...
dyld4::APIs::runAllInitializersForMain
dyld4::prepare
start

Instruction stream at RIP (first bytes): c4 e2 f9 f7 d1 ... — VEX 3-byte prefix + AVX2/BMI2 opcode.

Workaround

Replace the crashing native binary with a symlink to the Node-based claude-code CLI (CPU-agnostic):

BIN=~/Library/Application\ Support/Zed/node/cache/_npx/<hash>/node_modules/@anthropic-ai/claude-agent-sdk-darwin-x64/claude
mv "$BIN" "$BIN.avx2-bak"
ln -s /usr/local/lib/node_modules/@anthropic-ai/claude-code/cli.js "$BIN"

The Node-based claude-code CLI accepts the same args the ACP layer sends (--output-format stream-json, --input-format stream-json, --session-id, --replay-user-messages, --include-partial-messages, --permission-prompt-tool, etc.). After the swap the agent works normally.

Suggested fix

One or more of:

  1. Build the native claude-agent-sdk-darwin-x64 binary targeting a baseline x86_64-v1 CPU (or at least pre-AVX2/pre-BMI2).
  2. Ship separate binaries per CPU feature level and select at runtime via sysctlbyname("hw.optional.avx2_0", ...).
  3. Detect unsupported CPU at install/launch and fall back to the Node-based claude-code CLI.
  4. At minimum, exit with a clear diagnostic instead of SIGILL, so ACP clients can surface a useful error rather than an infinite spinner.

View original on GitHub ↗

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