Activity

1. github-actions

   assigned

   Brendonovich

   on May 23, 2026
2. github-actions commented on May 23, 2026

   

   github-actionsBot

   on May 23, 2026 – with GitHub Actions

   Contributor

   More 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
3. bitsnaps commented on Jun 1, 2026

   

   bitsnaps

   on Jun 1, 2026

   More actions

   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!
4. linletian commented on Jun 18, 2026

   

   linletian

   on Jun 18, 2026

   More actions

   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.
5. tobocop2 commented on Jul 15, 2026

   

   tobocop2

   on Jul 15, 2026

   More actions

   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/[email protected]	ea2f223e…
   @oven/[email protected]	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.
6. tobocop2 commented on Jul 15, 2026

   

   tobocop2

   on Jul 15, 2026

   More actions

   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.

   👍React with 👍1Reacted by Ibrahim.H
7. tobocop2 commented on Jul 28, 2026

   

   tobocop2

   on Jul 28, 2026

   Last edited by tobocop2

   More actions

   Sorry to ping you @thdxr and @rekram1-node, but since you both dug into the bun AVX crash in #13282 and have merged PRs in oven-sh/bun, you're the best-placed people to help move this.

   My upstream PRs oven-sh/WebKit#290, oven-sh/WebKit#292, and oven-sh/bun#34207 (a real non-AVX2 macOS baseline for bun) are open with no reviews, and this can't be fixed on opencode's side.

   In the meantime my fork has a confirmed-working build at https://github.com/tobocop2/opencode-bun-pre-avx2-mac/releases/latest (17 opencode downloads so far, with a confirmed success on real Ivy Bridge hardware in #24876).
8. tobocop2 commented on Aug 5, 2026

   

   tobocop2

   on Aug 5, 2026

   More actions

   surfacing this again, my builds are getting downloaded regularly and I haven't even published this anywhere or advertised this outside of these github issues and PR's.

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

   I have 35 downloads at this point and that's without me remotely trying to advertise this anywhere outside of these comments. I need an opencode maintainers help to nudge the oven-sh team as that's the only way I think this can be taken seriosly.

   ❤️React with ❤️1Reacted by Ibrahim.H
9. JoeJoeflyn commented on Sep 16, 2026

   

   JoeJoeflyn

   on Sep 16, 2026

   More actions

   @tobocop2 ur fixed works right ?
10. neriousy commented on Oct 1, 2026

    

    neriousy

    on Oct 1, 2026

    Member

    More actions

    Closing as a duplicate of #8345, which tracks OpenCode crashing with an illegal instruction on older Intel CPUs (the "baseline" binary still needs AVX2). Please add your CPU model and 👍 there. The open PR for this can reference #8345.
11. neriousy

    closed this as a duplicateof zsh: illegal hardware instruction opencode #8345 on Oct 1, 2026