[Windows] v1.3.3 non-baseline binary segfaults on AMD Ryzen 7 PRO 8845HS — baseline works fine

[doomsday616]

Bug Description

After upgrading from v1.3.2 to v1.3.3, OpenCode crashes immediately on startup with a Bun segmentation fault. The crash happens during Bun's own initialization (within ~8ms), before any OpenCode logic runs.

The non-baseline binary (opencode-windows-x64) crashes. The baseline binary (opencode-windows-x64-baseline) works perfectly.

Root Cause Analysis

The opencode-windows-x64 package size changed dramatically between versions:

Version	opencode-windows-x64 (non-baseline)	opencode-windows-x64-baseline
1.3.2	150,714,991 bytes	150,715,000 bytes
1.3.3	200,424,047 bytes	200,424,056 bytes

Both non-baseline and baseline grew by ~50MB, suggesting a Bun runtime upgrade or recompilation in v1.3.3. The new non-baseline binary segfaults on this hardware while baseline works fine.

The CPU fully supports AVX2 (verified via IsProcessorFeaturePresent(40) = True), and the crash output even reports CPU: sse42 avx avx2 avx512 — so this is not a missing-AVX2 issue. The non-baseline Bun binary simply has a compatibility bug on this platform.

Reproduction

# Direct test — non-baseline crashes:
& "$env:APPDATA\npm\node_modules\opencode-ai\node_modules\opencode-windows-x64\bin\opencode.exe" --version
# Result: Segmentation fault

# Direct test — baseline works:
& "$env:APPDATA\npm\node_modules\opencode-ai\node_modules\opencode-windows-x64-baseline\bin\opencode.exe" --version
# Result: 1.3.3

SHA256 hashes confirm they are different binaries:

• opencode-windows-x64: AB7CB9E2B3352084BDA487F2E30CAB2D2500ECE437A06787BD509EA01174E6B2
• opencode-windows-x64-baseline: 5230698EA4BDA2C1F20ECCC91311E17E4AE7AF6F35347FD815BD8ADFAF711C73

Crash Output

============================================================
Bun v1.3.11 (af24e281) Windows x64 (baseline)
Windows v.win11_dt
CPU: sse42 avx avx2 avx512
Args: "...\opencode-windows-x64\bin\opencode.exe" "--version"
Elapsed: 8ms | User: 15ms | Sys: 15ms
RSS: 22.54MB | Peak: 22.54MB | Commit: 56.10MB | Faults: 5724
panic(main thread): Segmentation fault at address 0x7FF6D589D1A7
oh no: Bun has crashed. This indicates a bug in Bun, not your code.
https://bun.report/1.3.11/e_1af24e28AA4o24FmubqiMouqzwDCYKERNEL32.DLLut0LCSntdll.dll4oijBA2s//Bzl34uqB

Note: The crash output says "baseline" but the binary being executed is from the opencode-windows-x64 (non-baseline) package. This appears to be a misleading label in Bun's crash reporter.

Workaround

Setting OPENCODE_BIN_PATH to the baseline binary resolves the issue:

[System.Environment]::SetEnvironmentVariable(
  "OPENCODE_BIN_PATH",
  "$env:APPDATA\npm\node_modules\opencode-ai\node_modules\opencode-windows-x64-baseline\bin\opencode.exe",
  "User"
)

Environment

• OS: Windows 11 Enterprise, Build 26100
• CPU: AMD Ryzen 7 PRO 8845HS w/ Radeon 780M Graphics (Zen 4, full AVX2/AVX-512 support)
• Machine: HP ZBook Power 16 inch G11 A Mobile Workstation PC
• Node.js: v24.11.1
• npm: 11.6.3
• OpenCode: 1.3.3 (upgraded from 1.3.2 via npm install -g opencode-ai@latest)
• Installation method: npm install -g opencode-ai

Suggestion

Consider one of the following:

1. Add runtime fallback: If the primary binary crashes on launch, automatically retry with the baseline binary
2. Default to baseline on Windows: The performance difference is negligible for a CLI tool, and baseline avoids this entire class of bugs
3. Pin a known-stable Bun version: The Bun runtime upgrade in v1.3.3 introduced this regression

[github-actions]

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

• Windows: Installer should detect CPU capabilities and use baseline binary for CPUs without AVX2 #12553: Windows installer should detect CPU capabilities and use baseline binary — overlaps with the suggestion in this report to default to baseline or add runtime fallback
• OpenCode 1.1.59 crashes immediately on chat (Bun AVX crash) #13282: OpenCode 1.1.59 crashes immediately on startup with Bun AVX crash — similar startup crash symptoms

If your issue is distinct from those, please note the differences in a comment here.

[doomsday616]

Update: Closing — this is not an OpenCode or Bun bug.

After further investigation, the root cause turned out to be a file locking issue during in-place upgrade on Windows.

What actually happened

1. OpenCode v1.3.2 was running in Terminal Tab 1 (the .exe was locked by Windows)
2. A startup-sync plugin detected v1.3.3 and ran npm install -g opencode-ai@1.3.3
3. npm successfully updated package.json, JS files, and the baseline binary (which wasn't locked)
4. But the non-baseline .exe was locked by the running process — npm silently failed to overwrite it
5. Result: the non-baseline .exe remained at v1.3.2 (150MB) while everything else was at v1.3.3 (200MB)
6. Next launch: bin/opencode selected the non-baseline binary → v1.3.2 binary tried to load v1.3.3 code → version mismatch → segfault

Evidence

File	Expected (v1.3.3)	Actual on this machine
non-baseline exe	200,424,047 bytes	150,714,880 bytes (v1.3.2)
baseline exe	200,424,056 bytes	200,423,936 bytes (correct)
non-baseline modified	2026-03-27	2026-03-25 (never updated)

On another machine (NON-GM-DESKTOP) where OpenCode was not running during the upgrade, both binaries have identical hashes and work fine.

Fix

Close OpenCode, then:

npm install -g opencode-ai@1.3.3

This properly overwrites the stale .exe. No OPENCODE_BIN_PATH workaround needed.

Note for OpenCode team

This could affect any Windows user who auto-upgrades while OpenCode is running. npm does not treat a locked-file copy failure as a fatal error for optional dependencies — it silently skips the file. Consider documenting this caveat or adding a post-upgrade binary integrity check.