Stack overflow via recursive exception dispatch in bundled Bun on every outbound fetch (Windows 11, v1.18.4 and v1.18.11)

Summary

On one Windows 11 machine, every opencode invocation that performs an outbound network fetch crashes with an unhandled 0xC0000005 ACCESS_VIOLATION. A full crash dump shows the mechanism: a recursive exception-dispatch loop inside the bundled Bun runtime during the fetch, ending in stack exhaustion (the faulting write lands one page below the bottom of the fetch thread's stack, from a stack-probe stub at opencode.exe+0x1fc0).

Local-only code paths (--version, --help, auth list, serve until its update check fires) work. Any path that fetches (LLM call in run, models catalog fetch when uncached, plugin-manifest registry resolution) dies instantly.

Environment

• Windows 11 Home 10.0.26200, x64
• opencode installed via npm i -g opencode-ai (shim execs the self-contained opencode.exe)
• Reproduces on v1.18.4 and v1.18.11 identically; the opencode-windows-x64-baseline binary is worse (segfaults even on --version)
• Reproduces in both Git Bash and PowerShell, from any working directory

Reproduction

opencode run "Reply with exactly the word OK and nothing else."
# exits 139 (Git Bash) / -1073741819 = 0xC0000005 (PowerShell), no output, no log entries

opencode models crashes the same way until the catalog is cached; once models.dev is cached it succeeds because no fetch happens.

Crash dump analysis

Captured with ProcDump (-ma -e), unhandled C0000005, full 982 MB dump, parsed with the minidump Python library:

ExceptionCode:    EXCEPTION_ACCESS_VIOLATION
ExceptionAddress: 0x00007ff7114b1fc0   (opencode.exe+0x1fc0, early-image stub / stack probe)
Violation:        WRITE of 0x0000001b83600bb8

Faulting thread stack: 0x1b83601000 .. 0x1b84800000
Write target:          0x1b83600bb8   (one page BELOW the stack bottom)

The faulting thread's stack scan shows the same ntdll frames repeating over and over (ntdll+0x3ae640, ntdll+0x2e4d4c, ntdll+0x3b4c28, interleaved with two alternating opencode.exe frames at +0x1fd4/+0x3da0 and +0x2828c30/+0x383ed47), i.e. exception dispatch re-entering itself until the stack is gone. Whatever the initial exception is, the handler path re-faults recursively instead of surfacing an error.

Ruled out on this machine

• Config or state corruption: pristine XDG_CONFIG_HOME and XDG_DATA_HOME still crash
• opencode version: 1.18.4 and 1.18.11 both crash; clean reinstall does not help
• Machine TLS stack: standalone Bun 1.3.14 AND 1.3.9 (bun -e "await fetch(...)") fetch the same URLs fine
• OS changes: no Windows updates installed in the regression window (last good run Jul 21, first dead run later the same day)
• Certificate store: no root/CA certs added in the window
• Winsock LSPs: catalog is all-Microsoft
• Defender: no detections logged for the binary
• WER: no crash reports (the crash bypasses WER entirely; only a debugger catches it)

Possibly related existing reports of bundled-Bun Windows segfaults: #14204, #11339.

Notes

The full dump is available privately on request (it contains session credentials, so it is not attached). Happy to run instrumented builds or additional captures on the affected machine.