macOS x64 "baseline" binary requires AVX2/FMA — crashes on Ivy Bridge CPUs

[KrishanCHOUDHARY-1998]

Description

When installing opencode v1.15.10 on a Mac with an Ivy Bridge CPU (Core i7-3520M), the binary crashes immediately with exit code 132 (SIGILL — illegal instruction).

Steps to reproduce:

curl -fsSL https://opencode.ai/install | bash
opencode --version # exits with code 132
Or via npm:

npm i -g opencode-ai

postinstall fails with "could not find package opencode-darwin-x64-baseline"

Investigation findings:

sysctl -n hw.optional.avx2_0 returns 0 — no AVX2 support
sysctl -n hw.optional.fma returns 0 — no FMA support
opencode-darwin-x64 and opencode-darwin-x64-baseline from v1.15.10 are byte-identical (same MD5, same 112853072 byte size), so the baseline build is not actually a different target
otool -h shows cpusubtype 3 (CPU_SUBTYPE_X86_64_H — Haswell) for both
Even v1.15.9's opencode-darwin-x64-baseline binary crashes the same way on this CPU
Ivy Bridge (2012) supports x86-64-v2 but not x86-64-v3 (which requires AVX2 + FMA, introduced in Haswell 2013). The macOS "baseline" builds appear to still target x86-64-v3/Haswell.

Expected behavior: The baseline binary should either target x86-64-v2 or be clearly documented as requiring Haswell or newer.

System:

MacBook Pro, Intel Core i7-3520M @ 2.90GHz
macOS 24.6.0 (Darwin)
opencode v1.15.10

Plugins

No response

OpenCode version

v1.15.10

Steps to reproduce

npm error code 1
npm error path /usr/local/lib/node_modules/opencode-ai
npm error command failed
npm error command sh -c node ./postinstall.mjs
npm error It seems your package manager failed to install the right opencode CLI package. Try manually installing "opencode-darwin-x64-baseline" or "opencode-darwin-x64".

Screenshot and/or share link

No response

Operating System

No response

Terminal

No response

[github-actions]

This issue might be a duplicate of existing issues. Please check:

• Crash on older Intel Macs (Illegal instruction / AVX2 incompatibility) #24876: Crash on older Intel Macs (Illegal instruction / AVX2 incompatibility) — same root cause, same CPU generation (Ivy Bridge/Mac), same SIGILL crash
• zsh: illegal hardware instruction opencode #8345: zsh: illegal hardware instruction opencode — same illegal instruction crash on older Intel Mac
• OpenCode 1.1.59 crashes immediately on chat (Bun AVX crash) #13282: OpenCode 1.1.59 crashes immediately on chat (Bun AVX crash) — AVX-related crash on launch

[bitsnaps]

I'm getting a similar issue, even after globally installing opencode-darwin-x64, mostly likely because of macOS compatibility issue:

dyld: Symbol not found: _ubrk_clone
  Referenced from: /usr/local/bin/pnpm/global/5/node_modules/opencode-ai/bin/opencode.exe (which was built for Mac OS X 13.0)
  Expected in: /usr/lib/libicucore.A.dylib

maybe I can install an older version!

[linletian]

Important update: The problem may not require a new build target — the Linux baseline binary already works on the same CPU.

I tested this on an Intel Xeon E5-1680 v2 (Ivy Bridge, no AVX2) — same crash on macOS, exact same SIGILL. But then in a VMware Ubuntu VM on the same physical machine, opencode-linux-x64-baseline --version outputs 1.17.8 without any crash.

Both binaries share the same BuildID (c30f169b...), embedding the same Bun/JavaScriptCore runtime. The difference: Linux baseline's JSC FTL JIT does runtime cpuid detection and falls back to SSE4.2/AVX1 when AVX2 is absent. macOS baseline's JIT hardcodes AVX2.

The fix: align macOS baseline JIT behavior with Linux — add runtime CPU feature fallback, not a new build target.

[tobocop2]

I traced this end to end on real pre-AVX2 hardware. Short version: opencode's packaging is fine — the bug is upstream in bun, which has no real x64 macOS baseline build. Details below, including corrections to two theories already in these threads.

TL;DR

• opencode-darwin-x64-baseline is byte-identical to opencode-darwin-x64.
• That's because the bun runtime it embeds is identical: @oven/bun-darwin-x64-baseline == @oven/bun-darwin-x64 — both are the AVX2 build.
• bun ships a real baseline for linux but not for macOS, because there is no baseline macOS WebKit prebuilt to link against.
• So on a pre-AVX2 Mac there is no working binary, and opencode can't produce one until bun does.

The root-cause chain

1. On a pre-AVX2 Mac, postinstall.mjs correctly prefers opencode-darwin-x64-baseline.
2. But that package embeds the AVX2 bun runtime, so --version (verifyBinary()) SIGILLs.
3. It falls through to opencode-darwin-x64 — also AVX2 — which also SIGILLs.
4. The candidate list is exhausted → the "failed to install the right package" error in this issue.

Two theories in these threads that are incomplete

"opencode builds -baseline but doesn't publish it" (#24876).
Not quite — opencode does publish opencode-darwin-x64-baseline, and build.ts requests bun-darwin-x64-baseline correctly. The artifact exists; it's just identical to the default because bun's darwin baseline is identical to bun's darwin default.

"Linux baseline works on the same CPU, so it only needs runtime dispatch, not a new build target" (#32850 → here).
The linux baseline works because it's compiled -march=nehalem (SSE-only) with AVX2 kernels behind explicit runtime dispatch. The darwin binary is -march=haswell, so the compiler emits AVX2 throughout — not behind any dispatch. You can't add runtime dispatch to a -march=haswell binary after the fact; it has to be recompiled at -march=nehalem. That is a new build target — a real darwin baseline.

Why bun has no darwin baseline

From bun's own scripts/build/deps/webkit.ts: baseline WebKit prebuilts (-march=nehalem) exist for Linux amd64 and Windows amd64, but not for macOS. bun links a prebuilt WebKit, so without a baseline macOS WebKit there's no baseline macOS bun. It's systemic (same at bun 1.2.20).

Evidence

Each step below is something anyone can reproduce with curl — no bun internals involved.

1. The two darwin bun packages are literally the same file.
I downloaded both npm packages and hashed the bun binary inside each:

npm package	sha256 of bin/bun
@oven/bun-darwin-x64@1.3.14	ea2f223e…
@oven/bun-darwin-x64-baseline@1.3.14	ea2f223e…

Identical hash = byte-for-byte the same binary. A "baseline" package is supposed to be a different, lower-CPU-requirement build. Here it's the exact same file.

2. That shared binary is the AVX2 build — the one old CPUs can't run.
Disassembling it (Mach-O, x86_64) shows 248,019 AVX2 instructions and 7,049 AVX-512 instructions. Those are exactly the instructions a pre-2013 CPU without AVX2 cannot execute, which is what produces the SIGILL.

3. Linux proves bun can do this right — it just doesn't for macOS.
Running the same comparison on the linux packages: the default and baseline are different binaries, and the baseline has far fewer AVX2 instructions:

npm package	AVX2 instruction count
@oven/bun-linux-x64 (default)	299,928
@oven/bun-linux-x64-baseline	12,328

So bun genuinely builds a low-AVX2 baseline for linux. There's no equivalent for macOS — the darwin "baseline" is just a copy of the AVX2 default.

4. Confirmed on real pre-AVX2 hardware.
I rented a Sandy Bridge Xeon (has AVX + SSE4.2, no AVX2/FMA — the same CPU class as the affected Macs). Running the AVX2 build there, once it touches the text-processing path, it crashes with a segfault after ~21 seconds and ~3.9 GB of memory. The real SSE4.2 baseline build runs fine on the same machine. This confirms the AVX2 build is what crashes, and that a proper baseline would work.

What this means for opencode

The real fix is upstream upstream in bun (I can file it with this same evidence): bun needs a baseline macOS WebKit + a darwin-x64-baseline release target. Until then, two things would help users here:

1. Stop advertising opencode-darwin-x64-baseline while it's identical to the default — it reads as a working fallback but isn't.
2. Make the install error name the real cause — "this CPU lacks AVX2; x64 macOS builds currently require Haswell (2013) or newer" — instead of a generic "failed to install the right package," so users stop retrying.

This is the same underlying bug as #24876 and the closed #32850 / #26877 / #26878 / #13379.

[tobocop2]

Update — root cause found, upstream fix open, and there are builds you can try.

What's actually wrong

bun ships no baseline macOS build. @oven/bun-darwin-x64-baseline is byte-identical to @oven/bun-darwin-x64 (both the AVX2 build), which is why opencode's -baseline Mac binary is too. That's because oven-sh/WebKit never builds a baseline macOS WebKit — bun-webkit-macos-amd64-baseline.tar.gz returns HTTP 404.

opencode's own packaging is fine — build.ts requests bun-darwin-x64-baseline correctly; there just isn't a real one upstream.

Full evidence: oven-sh/bun#34206

Upstream fix (open now)

• macOS: build a baseline (non-AVX2) x64 WebKit oven-sh/WebKit#290 — builds the missing baseline macOS WebKit
• macOS: build a real darwin-x64 baseline oven-sh/bun#34207 — makes bun ship a real darwin-x64-baseline (draft; gated on the WebKit PR)

Builds you can try today

👉 https://github.com/tobocop2/opencode-bun-pre-avx2-mac/releases/latest

I built a baseline bun and compiled opencode against it:

binary	AVX2 (ymm) instructions
shipped opencode-darwin-x64-baseline	248,019
this build	14,407
@oven/bun-linux-x64-baseline (verified working on real pre-AVX2 hardware)	12,328

I need testers — I couldn't test this on a real Mac

No cloud provider rents a pre-AVX2 Intel Mac, so I verified the recipe on a pre-AVX2 linux box instead (the baseline runs opencode run to completion there; the AVX2 build crashes after ~21s / ~3.9 GB). If you have one of these Macs, I'd genuinely appreciate a report either way:

chmod +x opencode-darwin-x64-baseline
./opencode-darwin-x64-baseline --version

Unofficial builds — not affiliated with oven-sh or anomalyco, just a stopgap until the PRs land.