Bundled OpenCode x64 binaries can crash with SIGILL / invalid opcode; baseline package may not be truly baseline #33595

Description

I maintain a downstream tmux/multi-agent setup that can run OpenCode lanes. We have been tracking an OpenCode/Bun native crash bucket here:

• downstream issue: https://github.com/NEXTAltair/multi-agent-shogun/issues/2

The original downstream symptom was Illegal instruction / core dump / WSL trap invalid opcode while running OpenCode. It was first noticed on an ashigaru5 + OpenCode + openrouter/x-ai/grok-4.3 lane, but after re-checking the evidence I do not think this should be treated as Grok-specific. The crash locus looks below the model/provider layer: bundled OpenCode native runtime / Bun / release packaging compatibility.

I cannot currently reproduce the crash locally, so I am not claiming an exact failing instruction or exact fixed version. I am opening this to connect the downstream evidence with existing OpenCode issues about SIGILL, embedded Bun, and baseline-package selection.

Current local result

Environment checked:

• WSL2 kernel: 6.6.87.2-microsoft-standard-WSL2
• CPU: AMD Ryzen 9 9950X
• OpenCode: 1.17.9, newly installed via npm install -g opencode-ai

Smoke checks did not reproduce the crash:

• opencode --version x10: 0 SIGILL
• direct modern binary run --help x5: 0 SIGILL

Also, on the same physical machine, both host WSL and a Docker devcontainer expose avx512f and can execute a minimal zmm/AVX-512 probe. So the theory "the same-machine devcontainer lacks AVX-512" is false for this host.

Packaging/binary observation

In the local 1.17.9 npm installation, these Linux x64 package binaries appeared byte-identical:

• opencode-linux-x64
• opencode-linux-x64-baseline

Both also appeared to contain many zmm / AVX-512 instructions in disassembly. The rough local counts were:

This matches a concerning pattern already reported in #27137, where modern and baseline packages had the same SHA. If the baseline package is identical to the modern package, users on older CPUs or masked virtualized CPU feature sets may have no real fallback.

Related upstream issues I found

• opencode exits immediately with Illegal instruction on WSL2/Linux (ACP unusable) #18411: WSL2/Linux Illegal instruction; both modern and baseline binaries fail.
• Crash on older Intel Macs (Illegal instruction / AVX2 incompatibility) #24876: x64 baseline / packaging mapping discussion; a comment points at packages/opencode/script/build.ts and baseline asset mapping.
• [linux] opencode silently exits (code 0) on x86_64 CPUs without AVX2 support when installed via npm #20116: npm install can choose the wrong binary and wrapper signal handling can hide a native signal exit.
• [Windows] OpenCode binary is compiled with Bun 1.3.5, causing LSP crashes/blocks despite system Bun 1.3.8 #11824 and [Windows] Upgrade embedded Bun runtime from v1.3.5 — LSP broken due to spawn segfault #11648: system Bun upgrades do not help because OpenCode uses embedded Bun in the bundled executable.
• launch opencode 1.17.00 tui may cause crash #31607: OpenCode 1.17.0 / Bun 1.3.14 crash reports; maintainer asked for Linux segfault reports.
• [Bug] Illegal instruction crash on Windows due to missing AVX2 CPU support (baseline binary also fails) #31155: Windows baseline/no-AVX2 path still failing.
• OpenCode Native Runtime Crash: SIGILL / Invalid Opcode #27137: native runtime SIGILL / invalid opcode with modern and baseline package binaries having the same SHA.

What I am asking maintainers to check

1. Verify that opencode-linux-x64 and opencode-linux-x64-baseline release/npm artifacts are actually distinct.
2. Verify npm optional package mapping and postinstall/wrapper CPU-feature selection for x64 Linux, Windows, and macOS.
3. Add a CI/release check that baseline x64 artifacts do not assume AVX2/AVX-512 instructions.
4. If a native child exits by signal (SIGILL, SIGBUS, SIGSEGV), make the wrapper print a non-zero diagnostic instead of silently succeeding or hiding the signal.
5. Document what users should collect for SIGILL/native runtime crashes.

Evidence I can provide if it recurs

At the moment this no longer reproduces in my local setup. If it recurs, I can provide:

• dmesg trap invalid opcode line and ip
• crashing binary path, package name, version, file size, SHA
• objdump around the failing ip
• bun.report URL/path or core dump path if produced
• CPU flags and WSL/kernel details
• model/provider/lane and immediately preceding action in the downstream orchestrator

OpenCode version

1.17.9

Steps to reproduce

I do not have a deterministic runtime crash reproducer right now. The packaging check that produced the concerning observation was:

1. Install opencode-ai@1.17.9 from npm on Linux x64 / WSL2.
2. Locate the installed opencode-linux-x64 and opencode-linux-x64-baseline package binaries.
3. Compare file size and SHA/checksum.
4. Disassemble or scan the binaries for zmm/AVX-512 instructions.
5. Observe that modern and baseline appear byte-identical and both include zmm/AVX-512-heavy code.

Screenshot and/or share link

Downstream evidence thread: https://github.com/NEXTAltair/multi-agent-shogun/issues/2

Operating System

WSL2 Linux x64

Terminal

tmux / bash