[BUG] 2.1.113 crashes with SIGILL "illegal hardware instruction" on Ivy Bridge (AVX2-less) Intel Macs — regression from 2.1.112

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/50384
2. https://github.com/anthropics/claude-code/issues/50190
3. https://github.com/anthropics/claude-code/issues/37277

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

Adding hard data from testing every version between 2.1.107 and 2.1.114 on a MacBook Pro Mid-2012 (i7-3520M, Ivy Bridge — has AVX1 but no AVX2/BMI2):

| Version | cli.js in npm tarball | Runs under Node.js |
|---------|------------------------|--------------------|
| 2.1.108 | Yes | Yes |
| 2.1.109 | Yes | Yes |
| 2.1.110 | Yes | Yes |
| 2.1.111 | Yes | Yes |
| 2.1.112 | Yes | Yes |
| 2.1.113 | No | SIGILL |
| 2.1.114 | No | SIGILL |

2.1.112 is the last usable version. The cli.js → Bun-only transition happened at 2.1.113.

For anyone on similar hardware, a working setup: install the tarball to a versioned directory and exec cli.js via a Node.js wrapper:

#!/usr/bin/env bash
exec /path/to/node "$HOME/.local/opt/claude-code-current/cli.js" "$@"

Symlink claude-code-current to the active version directory — rollback is one ln -sfn away.

(Closing my duplicate #50684 in favour of this one.)

Root cause analysis — it's a packaging change, not a Bun regression

Dug into the npm tarballs for both sides of the cutoff. The crash isn't caused by a Bun version bump — it's caused by removing the Node.js code path entirely.

2.1.112 tarball (last working):

package/cli.js          ← 13.5MB bundled JS, runs under any Node.js
package/package.json
package/vendor/ripgrep/
package/vendor/audio-capture/

2.1.113+ tarball (broken on pre-Haswell):

package/cli-wrapper.cjs  ← thin launcher, resolves + spawns native binary
package/install.cjs      ← postinstall: copies native binary from optional dep
package/bin/claude.exe   ← placeholder, overwritten by install.cjs
package/package.json     ← optionalDependencies: @anthropic-ai/claude-code-darwin-x64 etc.

The cli-wrapper.cjs header says _"users can run node cli-wrapper.cjs directly and pay the Node-process overhead"_ — but it doesn't run JS-on-Node. It just spawnSync()s the platform binary:

const binaryPath = getBinaryPath()
const result = spawnSync(binaryPath, process.argv.slice(2), {
    stdio: 'inherit',
    env: { ...process.env, CLAUDE_CODE_INSTALLED_VIA_NPM_WRAPPER: '1' },
})

So there is no fallback path. If the native binary SIGILLs, the user is stuck.

The @anthropic-ai/claude-code-darwin-x64 binary is a 196MB Mach-O with AVX2-dependent code paths (confirmed via strings | grep AVX2). It's a Bun single-file executable with the JS application baked in — not extractable for Node.js.

What this means for a fix

This isn't a "rebuild Bun with -march=x86-64-v2" situation (though that would also work). The simplest fix is continuing to ship cli.js in the tarball — it was there for every version up to 2.1.112 and ran perfectly on all hardware. The cli-wrapper.cjs fallback could detect SIGILL from the native binary and exec cli.js under Node instead.

Working setup for anyone stuck

# Install last cli.js version to its own directory
cd /tmp && mkdir claude-upgrade && cd claude-upgrade
npm pack @anthropic-ai/claude-code@2.1.112
tar xf anthropic-ai-claude-code-2.1.112.tgz
cp -R package ~/.local/opt/claude-code-2.1.112
ln -sfn ~/.local/opt/claude-code-2.1.112 ~/.local/opt/claude-code-current

# Wrapper at ~/.local/bin/claude
#!/usr/bin/env bash
exec /path/to/node "$HOME/.local/opt/claude-code-current/cli.js" "$@"

Works perfectly on MacBook Pro Mid-2012 (i7-3520M, Ivy Bridge) running macOS Sequoia 15.7.6. Performance is indistinguishable from the native binary path.

Thanks @johan-- for the two back-to-back deep dives — the version-by-version matrix and the tarball diff together make this a watertight bisection.

Consolidating the diagnosis for maintainers, since this thread now carries the full picture (including closed duplicate #50684):

Regression window: 2.1.112 → 2.1.113 (confirmed on two independent Ivy Bridge machines: i5-3470S iMac 2012 and i7-3520M MBP 2012).

Root cause: Not a Bun bump. The npm tarball stopped shipping cli.js at 2.1.113 and now only ships cli-wrapper.cjs, which spawnSyncs the native Bun single-file binary. That binary contains AVX2-dependent code paths (confirmed via strings | grep AVX2) and SIGILLs on any pre-Haswell x86-64 CPU. There is no Node.js fallback anymore.

Impact: Every Intel Mac older than mid-2013 is now permanently capped at 2.1.112 — 2012 iMacs, MacBook Pros, Mac Minis, Mac Pros, plus the broader OCLP user base keeping these machines on modern macOS. Not a huge cohort, but non-zero, and the previous two years of Claude Code releases all ran fine on this hardware.

Suggested fixes (either one resolves it):

1. Restore cli.js in the npm tarball as a Node.js fallback — exactly what 2.1.112 and earlier shipped. cli-wrapper.cjs could detect SIGILL from the native binary and re-exec under Node. Lowest-friction option since the code path existed two releases ago.
2. Rebuild the native binary with a baseline x86-64 target (-march=x86-64-v2 or equivalent Bun/Zig flags) to avoid AVX2/BMI2/FMA in hot paths.

Option 1 is probably cleaner — it preserves the native-binary fast path for modern CPUs while keeping a universal fallback for everyone else, at the cost of ~13 MB in the tarball.

Happy to test pre-release builds on the affected hardware if that's useful.

Good to hear that it was useful — Claude did a lot of the heavy lifting on the tarball diff and version sweep.

On the two options: Option 1 gets my vote for what it's worth. The hardware in this regression window isn't exotic — Ivy Bridge shipped in millions of Macs from 2012–2013, and the ones still in active use are mostly running Sequoia via OCLP, which means they're otherwise fully current. Silently dropping them off the release train for a packaging-level reason (rather than a genuine architectural one) feels like the kind of thing that'll quietly erode trust with a long tail of users who have no way to see it coming. 13 MB in the tarball is a cheap price for keeping that path open.

More than willing to test pre-release builds on the affected hardware as well.

and the ones still in active use are mostly running Sequoia via OCLP

I wouldn't say "most" - OCLP is a pain in the ear. none of my half dozen cheese graters are running sequoia. mind you, we'll never have true data for this - but it seems like 10.15 support for a node.js app is pretty approachable.........

while keeping a universal fallback for everyone else, at the cost of ~13 MB in the tarball.

not sure it needs to even been in the tarball - the various and many "native" binary's arent, right? the post-installer is supposed to install them (I have ran it, but haven't looked at it) and just silently-to-npm fails. that failure could be handled and pull the fallback version instead of native binary, from the same source...

Claude Code 2.1.113 has switched to a native executable (after npm deprecation was announced in January), which drops support for some platforms. Unfortunately we don't have plans to support pre-AVX2 Macs going forward. You can pin to the last JS bundle release https://www.npmjs.com/package/@anthropic-ai/claude-code/v/2.1.112 to continue using Claude Code for now.

This is unfortunate, especially given this : https://www.anthropic.com/engineering/april-23-postmortem

@ant-kurt - Could you suggest workarounds for the 3 issues mentioned in the article for users stuck with 2.1.112?

I pulled my MM 2012's out of mothballs for this and anthropic just pulled the rug from underneath because nobody can buy a MM 2026. Tell me it isn't what it looks like. I just subbed for Claude Max today btw - codex running fine on my 2012 macmini - nothing works better than proving regretful decisions.

@brian-kaler - exactly. I use my Macbook Pro 2012 for remote work (1-2 weeks at a time, ad-hoc periods) - it still beats a new Mac Air. I cannot understand their decision, but it now forces one to look at alternative suppliers.

btw - I use Claude Code for pure software engineering work, not vibe-coding or running agents 24/7 on Mac Minis.

I ended up just using a docker container to run claude-code on my 2012 mac mini with AVX1, as the linux version works just fine. I set up an alias to run the container with a bind mount to my current directory on my mac as the working directory for claude-code in the container.

I ended up just using a docker container to run claude-code on my 2012 mac mini with AVX1, as the linux version works just fine. I set up an alias to run the container with a bind mount to my current directory on my mac as the working directory for claude-code in the container.

docker? what is that supposed to mean. If its in docker wouldn't it still output illegal instruction?

docker? what is that supposed to mean. If its in docker wouldn't it still output illegal instruction?

No, because it is running essentially in a linux VM, and it appears that claude-code for linux does not require AVX2, or it at least has an AVX1 fallback path.

+1

I ended up just using a docker container to run claude-code on my 2012 mac mini with AVX1, as the linux version works just fine. I set up an alias to run the container with a bind mount to my current directory on my mac as the working directory for claude-code in the container.

That's a clever workaround for the AVX1 limitation. Did you notice any significant performance drop running it inside Docker compared to native execution? I'm facing the same issue and I'm stuck on version 2.1.98, this limitation is really putting me in a tight spot now.

I ran into the same issue with OpenCode on a MacBook Pro mid-2012 (Ivy Bridge, no AVX2 support). After some digging, the root cause was that Bun stopped compiling with AVX1 support on macOS (it still maintains it for Linux). Machines older than Haswell (2013) only have AVX1 and will crash with an illegal instruction error.

I was able to work around it for OpenCode by recompiling Bun from source with its existing baseline mode (-march=nehalem) enabled for macOS. The tricky part was a chicken-and-egg problem: building Bun normally requires Bun itself for code generation, but the official binary won't run on the target machine. The fix uses Docker to generate the JS artifacts on a Linux x86-64 environment first, then compiles natively with Zig and Clang. There's also a small WebKit config patch to stop the build from trying to download baseline artifacts that don't exist on macOS (macOS just reuses standard WebKit regardless of CPU baseline). I documented the full process here: https://github.com/orainlabs/bun/blob/macos-legacy-baseline/docs/building-on-legacy-macos.md

From there, rebuilding OpenCode from source with the patched Bun worked fine.

Unfortunately none of this is applicable to Claude Code since the source isn't public. I get that Anthropic isn't going to maintain a legacy build for pre-2013 hardware, but it would at least be nice to get a clear error message; something like "AVX2 required, not supported on this CPU", instead of a silent crash.

Getting this same issue on 2.1.145 on an Intel Atom N450 system running Linux.

Adding new evidence for this thread: a per-platform comparison of the Bun variants Anthropic ships in 2.1.175, which suggests the fix is a one-line packaging change already adopted on the other two platforms.

Inspecting each @anthropic-ai/claude-code-{platform}-x64@2.1.175 tarball with strings <binary> | grep "Bun v1.3.14":

| Platform package | Embedded Bun signature | Variant |
|---|---|---|
| claude-code-darwin-x64 | Bun v1.3.14 (2a41ca97) macOS x64 | normal (requires AVX2) |
| claude-code-linux-x64 | Bun v1.3.14 (2a41ca97) Linux x64 (baseline) | baseline |
| claude-code-win32-x64 | Bun v1.3.14 (2a41ca97) Windows x64 (baseline) | baseline |

Only darwin-x64 is missing the (baseline) marker. The current darwin-x64 binary even references the baseline download URL (bun-darwin-x64-baseline.zip) inside its own asset table, confirming the variant exists upstream and is officially supported by Bun.

Concretely confirmed on the same hardware (Mac Pro 2013, Xeon E5-1650 v2, Ivy Bridge, no AVX2): latest Claude Code runs under Windows and Linux on this machine, but SIGILLs on macOS. Pure packaging asymmetry, not a hardware limitation.

Suggested fix: switch the build for @anthropic-ai/claude-code-darwin-x64 from bun-darwin-x64 to bun-darwin-x64-baseline, matching the policy already applied to the Linux and Windows builds. No code changes required — a single change to the release pipeline.

I had opened #67973 with this same analysis before noticing it duplicates this thread — closing that one and consolidating here.

https://github.com/relecand/claude-desktop-avx-fix/tree/codex-fix-claude-sdk-cli-resolution

Fixes the Claude desktop app on older Intel Macs that lack AVX2 support.