Windows: embedded Bun 1.3.14 predates oven-sh/bun#35083 — opencode.exe segfaults whenever nProtect GameGuard (Helldivers 2) is running

Description

opencode.exe dies with a Bun panic whenever nProtect GameGuard is running — i.e. any time Helldivers 2 (or another GameGuard title) is open. GameGuard's npggNT64.des injects into running processes and raises a first-chance access violation inside its own __try/__except. Bun's vectored exception handler claims that fault before SEH can run, and treats it as fatal. An otherwise-idle opencode session survives indefinitely, then dies seconds after the game launches.

The crash signature is documented upstream in oven-sh/bun#34055 — Segmentation fault at address 0x3C, with npggNT64.des / USER32.dll in the stack.

This is already fixed in Bun. oven-sh/bun#35083 ("let foreign first-chance AVs reach SEH via JSC unwind info") merged 2026-07-23; the VEH now only claims faults originating inside Bun's own image. It first shipped in Bun 1.4.0 (2026-08-20).

OpenCode hasn't picked it up:

• package.json on main pins "packageManager": "bun@1.3.14" — 1.3.14 was released 2026-05-13, two months before the fix.
• Byte-scanning the shipped opencode.exe from 1.18.21 (published 2026-08-21, a day after Bun 1.4.0) finds only Bun v1.3.14; no 1.4 string is present.

The reason this needs fixing here rather than by the user: bun upgrade updates the standalone bun binary, not the runtime compiled into opencode.exe. There is no user-side workaround short of running opencode from source under a newer Bun, or moving to WSL2. It needs a rebuild against Bun >= 1.4.0.

Upstream context on the distribution problem: oven-sh/bun#40241.

Plugins

None.

OpenCode version

1.18.21 (npm opencode-ai, windows-x64)

Steps to reproduce

1. Start opencode on Windows and leave it idle at the prompt.
2. Launch Helldivers 2 (or any nProtect GameGuard title).
3. opencode exits with the Bun panic within seconds of GameGuard initialising.

Operating System

Windows 11 26100, x64

Terminal

Not terminal-specific — the fault is in the embedded runtime's exception handler, so it reproduces regardless of host terminal.