Native `claude` binary SIGILLs at startup on non-AVX2 x86_64 CPUs (Ivy Bridge / pre-Haswell)
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::findAndRunAllInitializers — before 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.112Node script — runs fine on same hardware
Reproduction
- 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. - Binary crashes immediately; client shows infinite loading spinner.
- 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:
- Build the native
claude-agent-sdk-darwin-x64binary targeting a baseline x86_64-v1 CPU (or at least pre-AVX2/pre-BMI2). - Ship separate binaries per CPU feature level and select at runtime via
sysctlbyname("hw.optional.avx2_0", ...). - Detect unsupported CPU at install/launch and fall back to the Node-based
claude-codeCLI. - At minimum, exit with a clear diagnostic instead of
SIGILL, so ACP clients can surface a useful error rather than an infinite spinner.
This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗