Bundled Bun binary lacks AVX baseline support — crashes on non-AVX CPUs

Having the same issue on M2 Pro CPU, latest macOS.

I'm running Claude Code from homebrew installation.

Seeing:

warn: CPU lacks AVX support, strange crashes may occur. Reinstall Bun or use *-baseline build:
https://github.com/oven-sh/bun/releases/download/bun-v1.3.11/bun-darwin-x64-baseline.zip

Macbook M2 Pro CPU. The same issue

claude --warn: CPU lacks AVX support, strange crashes may occur. Reinstall Bun or use *-baseline build:
https://github.com/oven-sh/bun/releases/download/bun-v1.3.11/bun-darwin-x64-baseline.zip

Same issue here too.

============================================================
Bun v1.3.11 (a2743b6d) Windows x64 (baseline)
Windows v.win10_cu
Args:
Features: no_avx2 no_avx
Elapsed: 3ms | User: 15ms | Sys: 0ms
RSS: 16.20MB | Peak: 16.22MB | Commit: 54.23MB | Faults: 4538

CPU lacks AVX support. Please consider upgrading to a newer CPU.
panic (thread 476624): attempt to use null value
oh no Bun has crashed. This indicates a bug in Bun, not your code.

still seeing this problem with Claude Code v2.1.85

Claude Code v2.1.109

warn: CPU lacks AVX support, strange crashes may occur. Reinstall Bun or use *-baseline build:
https://github.com/oven-sh/bun/releases/download/bun-v1.3.13/bun-darwin-x64-baseline.zip

Fixed the issue for me.
Had x86 installed after migrating from older MacBook.
Replaced with arm homebrew. No warnings after that

From my chat w/ Claude app on Xubuntu-24.04:

Lol, the 'Code' section in this app is also running into same problem. I wonder if there's a way to pin it's version to 2.1.14 4:00 PM Claude responded: Ha, yes — the Claude Code integration built into claude. Ha, yes — the Claude Code integration built into claude.ai is a separate instance and will have the same AVX problem if it's also using the Bun-based runtime. For the claude.ai Code integration, that's unfortunately not something you can control directly — it's managed by Anthropic's servers. Your best bet there is to file a bug report through the thumbs-down button or feedback mechanism, specifically mentioning: AMD Phenom II X6 1100T (pre-AVX, bare metal) Illegal instruction (core dumped) on any version past 2.1.14 Request for either a no-AVX build or a way to pin versions The more people report it from bare metal (as opposed to VMs), the harder it is for Anthropic to dismiss it as a hypervisor configuration issue.

Btw, per Claude app's suggestion, I had to remove the write permission on both the claude-code binary, and the download folder to prevent auto-update from working as anything above 2.1.14 needs AVX and I, sadly, don't have that on my CPU. So now I've claude-code CLI working (it's pinned to v2.1.14), but the 'code' in Claude app doesn't work. I hope dependency on AVX is removed, or if it's needed then a fork or a version pinning mechanism is provided. Would be great to have 'code' work in both the Claude app and the CLI with feature parity. Thanks.

Edit: I heard that this is also seen in hypervisor mode, so want to make it clear that mine is bare metal usage

Hitting this on a 2013 Mac Pro (Xeon E5-2697 v2, Ivy Bridge-EP), bare metal.

CPU has AVX but not AVX2:

$ sysctl -n machdep.cpu.features | tr ' ' '\n' | grep AVX
AVX1.0

Since AVX is present, Bun's runtime check passes and no warning prints. SIGILL on the first AVX2 instruction (Illegal instruction: 4, exit 132, dies in dyld init before main).

Bisect:

• 2.1.112: works (Node-based cli.js)
• 2.1.113 through 2.1.150: crash on launch

bun build --compile bakes the runtime into the 200MB Mach-O, so installing bun-darwin-x64-baseline system-wide doesn't help. No JS fallback shipped since 2.1.113.

Could you publish @anthropic-ai/claude-code-darwin-x64-baseline (and linux/win equivalents) compiled against baseline Bun? Same optionalDependency layout as the current per-platform packages.

Pinned to 2.1.112 for now to keep things working, but locked out of newer releases.

Additional repro — Intel Ivy Bridge (i7-3520M), macOS Sonoma

Adding another confirmed affected environment to strengthen this report.

Environment

• OS: macOS Sonoma 14 (Darwin 23.6.0, x86_64)
• CPU: Intel Core i7-3520M @ 2.90GHz (Ivy Bridge, 2012) — supports AVX but NOT AVX2
• Node.js: v25.9.0 (x64)
• Claude Code: crashes on any version newer than 2.1.112
• Install method: npm install -g @anthropic-ai/claude-code

Error

zsh: illegal instruction: 4  claude

Root Cause (confirmed)

The bundled Bun binary starting from v2.1.113 requires AVX2 instructions. The i7-3520M is a pre-Haswell CPU (Ivy Bridge, 2012) that supports AVX but not AVX2. Any Claude Code version using Bun 1.3.14 or later compiled without the -baseline flag will SIGILL immediately on launch.

Workaround

Pinning to the last working version:

npm install -g @anthropic-ai/claude-code@2.1.112

Related issues

• #64378 — same crash on Intel i5-3470S / Ivy Bridge / macOS (marked duplicate)
• #63609 — Illegal Instruction crash on CPUs without AVX since v2.1.113
• #34481 — SIGILL on Intel Westmere (Xeon X5675)

Request

Please ship the Bun baseline binary (compiled without AVX2) for macOS x64, or auto-detect CPU capabilities at install time and select the appropriate binary. This affects all Intel Macs from 2012 and earlier (Ivy Bridge and older), which are still officially supported under macOS Sonoma.

Related: If you're affected by this, there's an active discussion on #55520 proposing a clean fix — shipping both AVX + baseline Bun builds with runtime auto-detection, so all users are covered with zero tradeoff. Drop a 👍 there to help get it prioritized: https://github.com/anthropics/claude-code/issues/55520#issuecomment-4763182570

Working fix for no-AVX / no-AVX2 CPUs (tested on Intel Xeon X5690 / Westmere-EP)

I've been running Claude Code on a machine with zero AVX support (Intel Xeon X5690, 2010 Westmere-EP — hw.optional.avx1_0: 0, hw.optional.avx2_0: 0). The bundled bun binary hard-crashes with Illegal instruction on these CPUs.

I built a patched version that replaces bun entirely with esbuild (a pure Go binary with no AVX requirement) as the build/bundle toolchain:

Repo: https://github.com/genose\/claude-code-source-build-community-edition-noAVX-foroldtimer (branch: noavx_esbuild)

Key changes:

• Replaced bun devDependency with esbuild in package.json
• Added scripts/esbuild-runner.mjs with plugins to handle CJS/ESM shim edge cases that bun handled transparently
• Extended build-cli.mjs to invoke esbuild, create missing package.json stubs for extracted node_modules, and fix hoisting issues

Ask for Anthropic: Please ship the *-baseline bun build (no AVX) for users on older hardware, VMs, or cloud instances without AVX. A lot of perfectly capable machines (24-core Xeon workstations, Hyper-V VMs, older Xeons) are silently excluded. The baseline binary exists — it just isn't bundled.

Happy to upstream the esbuild approach as a PR if there's interest.

---
Quick install (installs as claudius command):

macOS / Linux:

curl -fsSL https://raw.githubusercontent.com/genose/claude-code-source-build-community-edition-noAVX-foroldtimer/noavx_esbuild/install.sh | bash

Windows (PowerShell):

irm https://raw.githubusercontent.com/genose/claude-code-source-build-community-edition-noAVX-foroldtimer/noavx_esbuild/install.ps1 | iex

claudius --version output: `` 2.1.88 (Claude Code — Community Edition no-AVX / old-timer) Patched by genose.org · github.com/genose/claude-code-source-build-community-edition-noAVX-foroldtimer Assisted by a custom no-AVX build of Claude Code itself — cheers Anthropic, heavily paid to drop old-timer CPU support 👴🖥️ ``

Fork PR (docs): https://github.com/genose/claude-code/pull/1

Status update on the upstream Bun fix:

The root cause on macOS is that @oven/bun-darwin-x64-baseline ships the same AVX2 binary as the standard build — the baseline WebKit artifact was never built due to a missing build lane in Bun's CI (oven-sh/bun/.buildkite/ci.mjs has baseline: true for Linux only).

A community PR fixing this is open and verified: oven-sh/WebKit#290

• Zero AVX2 instructions confirmed by disassembly
• CI validated on parallel PR oven-sh/WebKit#291
• JSC AVX detection fix (oven-sh/WebKit#198) already merged

The fix is 5 lines of CI config. The sole bottleneck is a Bun maintainer approving and merging oven-sh/WebKit#290, then oven-sh/bun#34207 can follow.

@Jarred-Sumner has been pinged directly on the WebKit PR. If others here are affected, adding a 👍 or comment on oven-sh/WebKit#290 would help signal priority.

This is a basic inclusivity failure — please compile for ALL users

Good news first: Bun has fixed the root cause in main by making the baseline (non-AVX) build the default for all x64. Once they cut a release, the blocker moves entirely to Claude Code.

The broader point that needs to be said: non-AVX hardware is not exotic. Pre-Haswell Intel CPUs cover millions of machines still in daily use. Default VM configurations (Hyper-V, VirtualBox, KVM) don't expose AVX to guests — meaning any developer or sysadmin running Claude Code in a VM is affected. This isn't a niche edge case, it's the default for a huge slice of your user base.

Shipping a tool that silently fails with SIGILL on these environments — with no warning, no fallback, no fix for nearly a year — sends a clear message: we built this for our own machines and didn't check further. That's not acceptable for a product people depend on. Your users are not all running high-end computers. Consider everyone, not just the people in your office.

When Bun ships the fix, please don't wait for the next scheduled update cycle. Cut a patch release of Claude Code with the updated Bun immediately. Your users have been waiting long enough.

I'd be glad to join the team and help ensure this kind of oversight doesn't happen again — better tooling, broader CI coverage, happier customers.

In the meantime: community workaround available here for anyone still blocked.

— @genose

If you are hitting this because Bun requires AVX and your CPU / VM does not have it, the Claude Code Community Edition no-AVX fork exists for exactly this situation.

It rebuilds Claude Code using Node.js + esbuild instead of Bun, so it runs on any CPU without AVX/AVX2 — bare metal, VMs, VPS, OpenStack, Proxmox KVM, Hyper-V, VirtualBox, QEMU, old Xeons, AMD pre-Bulldozer, all of it. One-line install:

curl -fsSL https://raw.githubusercontent.com/genose/claude-code-source-build-community-edition-noAVX-foroldtimer/noavx_esbuild/install.sh | bash

Currently at v2.1.283. The binary is called claudius (with a claude symlink for IDE/VS Code compat).

Honest note: the version number tracks upstream so the API gate passes, but the underlying app code is frozen at the v2.1.88 era — upstream switched to Bun-compiled bytecode at v2.1.126 and source maps are no longer obtainable. What you get: a working Node.js build that runs on your hardware, with fresh npm dependency packages at build time.

I hit the same AVX warning on an Apple Silicon Mac, but in my case this was not an AVX/Bun compatibility problem. Claude Code was picking up an old x86_64 Homebrew installation under Rosetta.

Environment:

• Mac Studio 2023, Apple M2 Max
• uname -m → arm64
• Claude Code 2.1.289 native install → arm64
• Old Homebrew Claude Code 2.1.205 → x86_64

Diagnostics:

$ which -a claude
/Users/go/.local/bin/claude
/usr/local/bin/claude

$ file ~/.local/bin/claude
Mach-O 64-bit executable arm64

$ file /usr/local/bin/claude
Mach-O 64-bit executable x86_64

The old installation was:

/usr/local/bin/claude
 -> /usr/local/Caskroom/claude-code/2.1.205/claude

while the current native installation was:

~/.local/bin/claude
 -> ~/.local/share/claude/versions/2.1.289

After refreshing the shell command cache / making sure the ARM64 binary was being used, the AVX warning disappeared.

I also removed the stale Intel Homebrew installation:

brew uninstall --cask claude-code
rehash

and verified:

file "$(command -v claude)"

now reports arm64.

So for Apple Silicon users seeing this warning, it is worth checking:

uname -m
which -a claude
type -a claude
file "$(command -v claude)"

If uname -m is arm64 but the Claude executable is x86_64, the AVX warning may simply be caused by an Intel Claude/Homebrew installation running through Rosetta rather than a CPU compatibility issue.

This is separate from the genuine no-AVX/no-AVX2 issue affecting older Intel CPUs.