zsh: illegal hardware instruction opencode

Description

open opencode in Terminal
Error message:
zsh: illegal hardware instruction opencode

Plugins

no

OpenCode version

1.1.19

Steps to reproduce

1.Download the installation package opencode-desktop-darwin-x64.dmg
2. opencode-desktop cannot display content
3. And an error occurs when executing the opencode command in the terminal:
zsh: illegal hardware instruction opencode

Screenshot and/or share link

No response

Operating System

Mac Pro (Late 2013),macOS 12.7.6, Intel Xeon E5,

Terminal

tabby 1.0.229

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

Install on Apple M3 Max #256: Install on Apple M3 Max - Reports the same zsh: illegal hardware instruction error on macOS
Segment failed #3352: Segment failed - Similar illegal instruction error on older hardware (IMac late 2009) with incompatible CPU instructions

Feel free to ignore if none of these address your specific case.

I am experiencing this same illegal hardware instruction error on a Mac Pro 6,1 (Late 2013) running macOS Sequoia via OpenCore Legacy Patcher.

The error occurs when the app tries to spawn the opencode-cli sidecar. Manually running the binary confirms the crash:

/Applications/OpenCode.app/Contents/MacOS/opencode-cli serve --port 54328
# Output: zsh: illegal hardware instruction

My CPU (Intel Xeon E5-1650 v2) supports AVX1.0 but lacks AVX2, which appears to be the requirement causing this crash. Here is my sysctl output for reference:

machdep.cpu.features: FPU VME DE PSE TSC MSR PAE MCE CX8 APIC SEP MTRR PGE MCA CMOV PAT PSE36 CLFSH DS ACPI MMX FXSR SSE SSE2 SS HTT TM PBE SSE3 PCLMULQDQ DTES64 MON DSCPL VMX SMX EST TM2 SSSE3 CX16 TPR PDCM SSE4.1 SSE4.2 x2APIC POPCNT AES PCID XSAVE OSXSAVE TSCTMR AVX1.0 RDRAND F16C

Since many Intel Macs (pre-2014) and Xeon-based Mac Pros (pre-2019) are still in use but lack AVX2, would it be possible to provide a baseline (x86-64-v2) build of the CLI sidecar?

just caught this bug on the latest version from the yolo curl | bash installer on Raspberry Pi 4 w/ Raspberry Pi OS 13 (Trixie)

just caught this bug on the latest version from the yolo curl | bash installer on Raspberry Pi 4 w/ Raspberry Pi OS 13 (Trixie)

can confirm, facing the same issue

just caught this bug on the latest version from the yolo curl | bash installer on Raspberry Pi 4 w/ Raspberry Pi OS 13 (Trixie)

can confirm, facing the same issue

I managed to fix it by downgrading to 1.1.53(and disabling auto-update!!!) which seems like the last build which doesn't have the new instructions from bunjs, but then trinity large free just started glitching out with tooling anyway, so I decided to stop using open code on my Pi for now because I have other, paid, options and I can't be using a fixed version which is flawed and quickly improving.

wanted to try opencode out. running opencode after installation, nothing happens, exits silently.
Kernel log contains:
[71965.865248] traps: opencode[82557] trap invalid opcode ip:407be50 sp:7ffcc1b5a8b0 error:0 in opencode[3d73e50,2ad7000+3b1c000].

Running on Debian 13 on an old i5-3320M (Ivy Bridge). Likely some native binary shipped with a dependency was compiled for newer instruction set?

@MartinEmrich

@MartinEmrich what version did u try?

TBH I do not know, as opencode --version does not produce any output either.
But I ran npm install -g opencode-ai yesterday and tried it never before (thus caching of older stuff unlikely), so it should be the newest one.

@rekram1-node

@rekram1-node I am happy to report that I tried to install again today (the new v1.2.2), and now it works.

#13379 seems to be a duplicate of my experience.

@rekram1-node

@rekram1-node I am happy to report that I tried to install again today (the new v1.2.2), and now it works.

#13379 seems to be a duplicate of my experience.

Me too, working again on my pi 4. Back to work! Thanks open code team

Mac Pro Mid 2010 still fails as of 2026-03-20 - opencode version: 1.2.27

Additional data point: Mac mini (Mid 2012), Intel i7-3720QM (Ivy Bridge), macOS 14.4.1 Sonoma.

The darwin-x64-baseline binary from v1.2.15 also crashes with SIGILL (exit code 132), same as the standard darwin-x64 build.

This is because Bun has no macOS x64-baseline build — only Linux and Windows get baseline binaries that drop the AVX2 requirement (ref: oven-sh/bun#17912). So the "baseline" designation on macOS is currently ineffective; the embedded Bun runtime still targets Haswell (AVX2).

$ /tmp/oc-baseline/opencode version
zsh: illegal hardware instruction  /tmp/oc-baseline/opencode
$ echo $?
132

CPU features confirm AVX1 present, AVX2 absent:

machdep.cpu.brand_string: Intel(R) Core(TM) i7-3720QM CPU @ 2.60GHz
machdep.cpu.features: ... AVX1.0 ...
machdep.cpu.leaf7_features: SMEP ERMS  (no AVX2)

I can reproduce this on another Mac Pro 6,1 (Late 2013) running macOS 12.7.6.\nCPU: Intel Xeon E5-1680 v2 (Ivy Bridge)\n\nOn this machine opencode and opencode --version both fail immediately with:\nzsh: illegal hardware instruction opencode\n\nLocal debugging shows:\n- macOS crash report: SIGILL / EXC_BAD_INSTRUCTION\n- lldb stops on shlxq %rax, %rcx, %rdx\n- CPU features include AVX1.0, but not AVX2/BMI2\n\nSo this looks consistent with the shipped macOS x64 binary requiring Haswell-era instructions that are not available on Ivy Bridge Xeons.\n\nI also filed a separate issue with the concrete crash details here: #26878

as of 2026-05-31 opencode version: 1.15.13 still fails

I experience this in my VM. I can provide the live ISO if this helps testing... Its 24 GiB though

opencode 1.17.8 still fails and not workaround yet
note that #13379 is closed and there has been a time where this has been working

Found the root cause: bun ships no baseline macOS build — @oven/bun-darwin-x64-baseline is byte-identical to the AVX2 build, because oven-sh/WebKit never builds a baseline macOS WebKit. Your Mac Pro (Late 2013) has an Ivy Bridge Xeon, which has no AVX2, so it SIGILLs.

PRs: oven-sh/WebKit#290 (builds the missing artifact) and oven-sh/bun#34207 (ships a real darwin-x64-baseline). Details: oven-sh/bun#32511.

Builds if you want to try one: https://github.com/tobocop2/opencode-bun-pre-avx2-mac/releases/latest — I don't have an Intel Mac to test on right now, so a report either way would help. I experienced this issue myself on my moms 2013 intel mac pro but don't have that right now.

@tobocop2

Confirming @tobocop2's root cause from the other side — a genuinely pre-AVX CPU. I hit this on a Xeon X5690 (Westmere, 2010): no AVX at all, only up to SSE4.2, so it's a strictly harder case than the Ivy Bridge / AVX1 machines above.

Same diagnosis: bun's own C/C++/Rust is built correctly for -march=nehalem, but the "baseline" macOS x64 build links the Haswell WebKit, whose bmalloc startup constructors contain BMI2/AVX2 (shlx / bzhi / blsr). Those run in a C++ static initializer before main(), so it SIGILLs at startup. oven-sh/WebKit ships no Nehalem/baseline macOS tarball, which is why the "baseline" label is currently ineffective on macOS (also tracked in oven-sh/bun#32512).

One thing worth flagging for oven-sh/WebKit#290 and oven-sh/bun#34207: clearing the startup SIGILL is necessary but not sufficient. I built bun from source with --baseline=true --webkit=local (-march=nehalem, WebKit compiled locally for nehalem). It passes --version and process.stderr.fd cleanly — but still SIGILLs/hangs under real load, because JSC's JIT emits AVX at runtime. A trivial JS loop hangs with the JIT on and runs instantly with it off. So a "baseline" build should be certified against a JIT-heavy workload, not just a startup smoke test.

Current working setup on the X5690:

bun built from source (nehalem + local WebKit), run with BUN_JSC_useJIT=0 → interpreted, no SIGILL. opencode 1.17.15 runs.
The Go opencode-cli sidecar also SIGILLs even as darwin-x64-baseline (VEX-encoded AVX); rebuilding from source with GOAMD64=v1 CGO_ENABLED=0 fixes that.
Everything is cross-built on a newer host and copied to the old Mac.

Offering our build. I'm happy to publish this AVX-free build for download — the from-source nehalem bun binary plus the GOAMD64=v1 opencode-cli — as a tagged GitHub release, or to feed the Westmere-verified binaries into @tobocop2's pre-avx2-mac release repo so there's a single place people can grab a known-good no-AVX macOS build. Say which you'd prefer.

Update procedure (the part that actually matters day to day — the two components move at very different speeds):

bun — slow, rare. Rebuild from source only when bun's pinned version bumps, via a small unattended script (--baseline=true --webkit=local, ~1.5 h on a fast host; WebKit is the long pole). Until a build passes a JIT-heavy test it ships with BUN_JSC_useJIT=0. A release would pin the exact bun commit + WebKit commit so it's reproducible.
opencode — fast, frequent. opencode releases almost daily, and every prebuilt release re-introduces the AVX2 runtime, so you can't just let it auto-update. The working pattern is to run opencode from source on the nehalem bun: git pull the opencode source + bun install, then cross-ship to the old Mac. Nothing to recompile — the AVX-free bun is reused.
Disable auto-update. Same point @euxaristia made above: with auto-update on, opencode will happily pull an AVX2 prebuilt over your working copy and break it again. Pin the version / turn the updater off.

So the download would be: a rarely-changing AVX-free bun (the hard artifact) + instructions to track opencode from source against it. Happy to set that up and post the link here if there's interest.

Will report back either way once I've tested your prebuilt builds on the Westmere box — if they clear a no-AVX-at-all CPU they'll clear every AVX1 machine in this thread.

@tobocop2

@tobocop2 Tested your v1.18.1-baseline build on a real pre-AVX Mac — Mac Pro 5,1 (2010), Xeon X5690 Westmere, macOS 14.7.8. CPU has sse42 popcnt only, no AVX/AVX2/BMI. Report below (both assets).

SHA-256

bun-darwin-x64-baseline (60,733,504 B): bede5eb3c917fa353d6b067fd7055d42774db7a7d5a09c21fa6cdd05e3d8efee
opencode-darwin-x64-baseline (103,282,752 B): 7daf210676d2efa9627619ab1823b141c861aa362f8a828db836472d9790e61f

Test	Result
`bun --version`	✅ OK → `1.4.0`, no SIGILL
`process.stderr.fd`	✅ OK → `2`
JIT-heavy loop (`for i<3e7: s+=Math.sqrt(i)`), JIT ON	❌ SIGILL (132) — panic `Illegal instruction`, banner says "CPU lacks AVX support"
same loop, `BUN_JSC_useJIT=0`	✅ OK
`opencode --version`	❌ SIGILL (132) (JIT on at startup)

tl;dr — the startup half is fixed, the JIT half is not.

The good news: the bmalloc/WebKit startup-constructor SIGILL is gone (--version, process.stderr.fd run clean), so your Nehalem WebKit artifact (WebKit#290) does its job for the pre-main() path. But JSC's JIT still emits AVX at runtime, so anything doing real work crashes. The crash banner itself prints Features: jsc no_avx2 no_avx and "CPU lacks AVX support" — i.e. it correctly detects there's no AVX, then emits AVX anyway. It only runs with BUN_JSC_useJIT=0 (interpreted, slow).

Two things worth flagging:

Despite the v1.18.1-baseline tag, the binary self-reports as Bun Canary v1.4.0-canary.1 (1e3511800), not 1.18.1.
The remaining fix probably isn't in WebKit's -march flags — it's JSC's JIT needing to gate VEX/AVX codegen on a runtime CPU check and fall back to SSE on Westmere/Nehalem. Right now --baseline + Nehalem WebKit fixes startup but the JIT tier is still unconditional AVX.

Happy to run more variants on this box if useful (it's a permanent no-AVX test machine).

That report nailed it, and your diagnosis was exactly right — it's the JIT, not the -march flags. I found the line and there's a build with the fix below.

Source/JavaScriptCore/assembler/MacroAssemblerX86_64.cpp at bun's pinned WebKit (4895f45d):

#if OS(DARWIN)
        s_avxCheckState = CPUIDCheckState::Set;   // never checks the CPU
#else
        // CPUID.1:ECX.AVX[28] + OSXSAVE[27] + XCR0[2:1] == 11b
#endif

On macOS, JSC assumes AVX rather than asking. supportsAVX() then feeds ~10 VEX-emitting codegen sites. That's why your banner prints no_avx / "CPU lacks AVX support" and emits AVX anyway — bun's detection is right, JSC's is hardcoded past it. oven-sh/WebKit#198 fixed this exact bug for Linux/Windows in April and guarded the new code with #if !OS(DARWIN), so Darwin kept the old assumption.

I reproduced your SIGILL without a Westmere box — an M1 running x86_64 bun under Rosetta 2, which also reports no AVX (CPU: sse42 popcnt). Identical to yours, which made this fast to iterate on:

	your X5690	M1 / Rosetta 2
`bun --version`	rc=0	rc=0
JIT loop	132	132
`BUN_JSC_useJIT=0`	rc=0	rc=0
`opencode --version`	132	132

Build with the fix: https://github.com/tobocop2/opencode-bun-pre-avx2-mac/releases/latest

873868a92fc1de5eb3bbae81a85e234186eb00f2b51da956e1835017d813d824  bun-darwin-x64-baseline
afe0fe21fc9b6ea43c33239aac990bb180c1025cc2d7044db5fab5ef4fc60915  opencode-darwin-x64-baseline

On Rosetta the JIT loop and opencode --version both go 132 → 0, and a 14-case suite (YarrJIT SIMD regex, strings/UTF-8, JSON, DFG/FTL tier-up, typed arrays) passes where the old build SIGILLs partway through. If it clears your X5690 too, that's a no-AVX-at-all CPU and it should cover every AVX1 machine in these threads.

Upstream: oven-sh/WebKit#292, tracked in oven-sh/bun#34215. Non-Darwin can't regress — the preprocessed output is byte-identical before/after (6287bfdf…), and on AVX hardware the new check returns Set, matching the old hardcode, so real AVX Macs are unchanged.

You were also right about the version. v1.18.1-baseline is opencode's version; the bun inside is built from bun main @ 1e35118008 and self-reports 1.4.0-canary.1 — not an official 1.3.14 baseline. I've said so plainly in the release now. Separately, opencode --version reported 0.0.0--<timestamp> because cloning a tag leaves a detached HEAD and the version derivation falls back to a preview string; it reports 1.18.1 in this build.

Taking you up on the X5690 offer — Rosetta gets me a no-AVX macOS, but it isn't real Westmere silicon and the two could diverge.

@rekram1-node

Surfacing this again. @rekram1-node sorry to ping but I think I need an opencode maintainers help to nudge the oven-sh team.

My builds are getting downloads (35 so far) and that's without me publicizing this in any capacity outside of these github issue comments.

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

@tobocop2

thank you @tobocop2 for this fix. using mac pro 2013 with avx1

thank you @tobocop2 for this fix. using mac pro 2013 with avx1

no problem!

Thanks for the report! OpenCode 2.0 is now out and development is focused on V2, so we're closing issues filed against OpenCode 1. Please upgrade (opencode upgrade --major, details: https://anoma.ly/notes/opencode-2-0), and if this is still relevant on 2.0, reopen this issue or open a new one with your 2.0 version.

— from 𝕺𝖕𝖊𝖓𝕮𝖔𝖉𝖊

Navigation Menu

Repository navigation

zsh: illegal hardware instruction opencode #8345

Description

Plugins

OpenCode version

Steps to reproduce

Screenshot and/or share link

Operating System

Terminal

2 remaining items

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

zsh: illegal hardware instruction opencode #8345

Description

Description

Plugins

OpenCode version

Steps to reproduce

Screenshot and/or share link

Operating System

Terminal

Activity

github-actions commented on Jan 14, 2026

taazkareem commented on Feb 8, 2026

euxarist commented on Feb 11, 2026

princejeshurun17 commented on Feb 11, 2026

euxarist commented on Feb 11, 2026

MartinEmrich commented on Feb 12, 2026

rekram1-node commented on Feb 13, 2026

MartinEmrich commented on Feb 13, 2026

MartinEmrich commented on Feb 14, 2026

euxarist commented on Feb 14, 2026

WolfgangFahl commented on Feb 24, 2026

the3asic commented on Feb 28, 2026

2 remaining items

linletian commented on May 11, 2026

WolfgangFahl commented on May 31, 2026

micartey commented on Jun 16, 2026

WolfgangFahl commented on Jun 20, 2026

tobocop2 commented on Jul 15, 2026

WolfgangFahl commented on Jul 15, 2026

WolfgangFahl commented on Jul 15, 2026

tobocop2 commented on Jul 15, 2026

tobocop2 commented on Aug 5, 2026

enoch-dev commented on Aug 25, 2026

tobocop2 commented on Aug 25, 2026

thdxr commented on Oct 11, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions