Claude Code CLI unusable on pre-Haswell Intel Macs (no AVX2) — need Node.js fallback or non-AVX binary
Description
Claude Code CLI cannot run on Intel Macs with pre-Haswell CPUs. Since the move to Bun-compiled single-file executables, versions whose npm tarball no longer includes cli.js crash immediately with SIGILL. The last usable version is 2.1.108 (the last to ship cli.js in the tarball).
This isn't the v2.1.15 regression fixed via WebKit/Bun 1.3.7 — that fix addressed a specific JIT bug. The underlying problem is that the @anthropic-ai/claude-code-darwin-x64 binary requires AVX2, which this CPU microarchitecture does not have.
Environment
- Machine: MacBook Pro Mid-2012 (MacBookPro9,2)
- CPU: Intel Core i7-3520M @ 2.90GHz (Ivy Bridge, 3rd gen)
- CPU features: SSE4.2, POPCNT, AVX1.0, AES, XSAVE — no AVX2, no BMI2
- OS: macOS Sequoia 15.7.6
- Memory: 16 GB
- Current working version: 2.1.107 via Node.js wrapper
- Latest version tested: 2.1.114 — SIGILL on launch
How the working install works
Versions up to ~2.1.108 ship cli.js in the npm tarball — a single bundled JS file that runs under Node.js, which JITs to whatever instruction set the CPU supports. I run it via a bash wrapper:
#!/usr/bin/env bash
exec /path/to/node "$HOME/.local/opt/claude-code-current/cli.js" "$@"This works perfectly. Performance is fine. But from 2.1.114 onward, the tarball only contains cli-wrapper.cjs + install.cjs, which resolve to the platform-specific Bun binary — and that binary SIGILLs.
What I've verified
npm pack @anthropic-ai/claude-code@2.1.108→ containscli.js→ runs fine under Nodenpm pack @anthropic-ai/claude-code@2.1.114→ nocli.js, onlycli-wrapper.cjs→ spawns@anthropic-ai/claude-code-darwin-x64binary → SIGILL- The darwin-x64 binary is a 196MB Mach-O executable with AVX2-dependent code paths (confirmed via
strings)
Request
Any of these would restore support for pre-Haswell x86_64 hardware:
- Continue shipping
cli.jsin the npm tarball alongside the Bun binary (it was there until recently) - Build the darwin-x64 binary with
-march=x86-64-v2(SSE4.2 baseline) instead of requiring AVX2 - Provide
cli-wrapper.cjsas a true Node.js fallback — currently it just spawns the native binary; it could fall back to bundled JS when the binary SIGILLs
Option 1 is the smallest change — the tarball already had cli.js for years. Users on older hardware pay the Node.js overhead; everyone else is unaffected.
Related issues
- #19907 (33 comments) — v2.1.15 AVX regression, fixed via Bun 1.3.7
- #5864 (24 comments) — original "compile without AVX2" request
- #19904 (14 comments) — "CPU lacks AVX support"
- #34481 (open) — SIGILL on Westmere Xeon
7 Comments
Found 3 possible duplicate issues:
This issue will be automatically closed as a duplicate in 3 days.
🤖 Generated with Claude Code
This is an important compatibility regression from the Bun-native binary packaging shift: pre-Haswell Intel Macs lose the Node.js fallback path and hard-crash with SIGILL because the shipped darwin-x64 binary assumes AVX2.
The key distinction in your report is that this is not the earlier Bun/WebKit-specific regression. Your Ivy Bridge CPU supports AVX1 but not AVX2/BMI2, and the native binary now requires instructions the hardware simply does not have. That means the failure happens before Claude Code can do anything useful, including reporting a friendly compatibility error.
The fact that 2.1.108 still works via
cli.jsunder Node is the clearest evidence for the right fallback design: JS-on-Node remains viable on this hardware even when the Bun-compiled single-file executable does not.There are two reasonable fixes:
cli.jsin the npm tarball (or a separate compatibility package)Option 2 is especially attractive because it avoids multiplying native build targets while preserving support for older but still usable hardware.
At minimum, the installer should detect unsupported CPU features and fail with an explicit message (
This binary requires AVX2; use compatibility install X) rather than crashing with SIGILL. Silent hardware de-support via packaging changes is rough on long-time users, especially when the last working path was removed without a documented migration path.Update: Probed every version between 2.1.107 and 2.1.114. The exact cutoff:
| Version |
cli.jsin tarball | Runs on Ivy Bridge ||---------|--------------------|--------------------|
| 2.1.108 | ✅ | ✅ |
| 2.1.109 | ✅ | ✅ |
| 2.1.110 | ✅ | ✅ |
| 2.1.111 | ✅ | ✅ |
| 2.1.112 | ✅ | ✅ |
| 2.1.113 | ❌ | ❌ SIGILL |
| 2.1.114 | ❌ | ❌ SIGILL |
2.1.112 is the last usable version for CPUs without AVX2. The
cli.js→ Bun-only transition happened between 2.1.112 and 2.1.113.Duplicate of #50466 — added version probe data and workaround there.
For anyone landing here: follow #50466 — same issue (Ivy Bridge / pre-Haswell SIGILL at 2.1.113+), with full root cause analysis and a working Node.js workaround in the comments.
@0xbrainkid good breakdown — same conclusion I reached in #50466, which has the version-by-version probe data and root-cause: it's a packaging change, not a Bun regression.
cli.jswas dropped from the npm tarball at 2.1.113, so there's no Node fallback path left —cli-wrapper.cjsonlyspawnSyncs the native Bun binary.Your "restore the Node.js fallback path" option is exactly the minimal fix —
cli.jsshipped in every tarball up to 2.1.112 and ran on all hardware.Worth subscribing to #50466 — this one's auto-closing as duplicate in a few days.
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.