Crash on older Intel Macs (Illegal instruction / AVX2 incompatibility)

[marcioganzer]

Description

Description

The opencode binary crashes immediately on launch on older Intel Macs with the following error:

EXC_BAD_INSTRUCTION (SIGILL)
Illegal instruction: 4

This happens before the application fully initializes (during dyld initializer phase).

---

Environment

• macOS: 13.7.4
• Machine: Macmini6,2 (Intel Ivy Bridge, 2012)
• CPU: x86_64 (supports AVX, but NOT AVX2)
• Installation method: Homebrew (anomalyco/tap/opencode)

---

Crash details

Relevant excerpt:

Exception Type:        EXC_BAD_INSTRUCTION (SIGILL)
Termination Reason:    Illegal instruction: 4

Thread 0 Crashed:
0   opencode  ...
...
dyld4::Loader::findAndRunAllInitializers

Instruction stream shows AVX-prefixed opcodes (e.g. c4 ...), which indicates usage of instructions not supported by this CPU.

---

Root cause (analysis)

The distributed binary:

opencode-darwin-x64.zip

appears to be compiled targeting a modern x86_64 CPU baseline (likely x86-64-v3 or -march=native), which requires AVX2.

However:

• Ivy Bridge CPUs only support AVX1, not AVX2
• Executing AVX2 instructions results in SIGILL (illegal instruction)

Because the Homebrew formula only downloads a prebuilt binary (no local compilation), there is no way to adapt the build to older CPUs.

---

Why this matters

This makes the tool unusable on:

• Intel Macs pre-Haswell (≈ 2013 and earlier)
• Any x86_64 CPU without AVX2 support

These machines are still relatively common in development environments.

---

Suggested fixes

1. Provide a baseline-compatible build

Publish an additional binary targeting a more compatible baseline, e.g.:

• x86-64 (v1/v2)
• or -march=nehalem / -C target-cpu=x86-64

Example naming:

opencode-darwin-x64-legacy.zip

---

2. Avoid -march=native in release builds

If currently used, this should be avoided for distributed binaries, as it makes them dependent on the build machine CPU.

---

3. Explicit target configuration

Depending on the toolchain:

• Rust

  RUSTFLAGS="-C target-cpu=x86-64"
  

• Go

  GOAMD64=v1
  

• Bun / Zig / others
  Ensure target is not implicitly x86-64-v3

---

4. (Optional) Document CPU requirements

If AVX2 is required by design, it would be helpful to explicitly document:

Requires x86_64 CPU with AVX2 support

---

Workarounds

Currently, there is no workaround via Homebrew, since it only installs the prebuilt binary.

---

Summary

• Crash is caused by AVX2 instructions on non-AVX2 CPU
• Not a macOS issue or misconfiguration
• Requires either a compatible build or documented requirement

Plugins

No response

OpenCode version

last

Steps to reproduce

run brew install anomaly/tap/opencode

Screenshot and/or share link

No response

Operating System

macOS 13.7.4

Terminal

native macOS terminal

[github-actions]

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

• Illegal Instruction (trap invalid opcode) on Ivy Bridge CPUs (AVX supported, AVX2 missing) #13379: Illegal Instruction on Ivy Bridge CPUs (AVX supported, AVX2 missing) — same CPU generation and root cause
• SIGILL on Intel Celeron J3455 (no AVX/AVX2) in OpenCode 1.1.64; older revision works #13432: SIGILL on Intel Celeron J3455 (no AVX/AVX2) — same SIGILL / missing AVX2 symptom
• SIGILL (Illegal Instruction) on Intel Xeon E3-1270 V2 (no AVX-512/AVX2 support) #12512: SIGILL on Intel Xeon E3-1270 V2 (no AVX2 support) — same root cause on non-AVX2 hardware
• opencode exits immediately with Illegal instruction on WSL2/Linux (ACP unusable) #18411: opencode exits immediately with Illegal instruction on WSL2/Linux — open issue with the same illegal instruction symptom

[marcioganzer]

This seems to be a distribution/packaging issue rather than a runtime bug.

The current release (opencode-darwin-x64) appears to be built targeting a modern x86_64 baseline (likely x86-64-v3 / AVX2). On CPUs without AVX2 support (e.g. Ivy Bridge), this results in an immediate SIGILL on startup.

From what I can see, the installer (or upstream tooling such as llm-agents) always selects the same binary, without considering CPU capabilities.

Suggested approach

A robust fix would be one of the following:

1. Provide multiple x86_64 builds

   • x86-64-v1 (baseline, no AVX2 — compatible with older CPUs)
   • x86-64-v3 (AVX2 optimized)

2. Select binary dynamically at install time

   • Detect CPU features (e.g. AVX2 support)
   • Download the appropriate build

3. Fallback strategy

   • Default to baseline build when CPU detection is not available

Why this matters

Without this, the current binary is unusable on:

• pre-Haswell Intel Macs
• any x86_64 CPU without AVX2

This is not a misconfiguration — the binary itself is incompatible with the CPU.

Happy to test a baseline-compatible build if one is provided.