Windows ARM64 native builds fail: bun:ffi unavailable in stable Bun, bun-pty ships x64-only DLL

[ataidecarlos]

Summary

Building and running opencode natively on Windows on ARM (arm64, e.g. Snapdragon X laptops) hits two runtime gaps. The build itself works with Bun 1.4.0 (packages/opencode/script/build.ts already lists a win32 arm64 target), but the TUI and #pty shell sessions break.

1. TUI renderer needs bun:ffi, which stable Bun disables on windows-aarch64

OpenTUI (@opentui/core) loads a native opentui.dll through bun:ffi. Stable Bun 1.3.x ships bun:ffi compiled out on windows-aarch64 (TinyCC has no ARM64 backend), so the TUI fails at startup with:

Failed to initialize OpenTUI render library: bun:ffi dlopen() is not available in this build (TinyCC is disabled)

Bun 1.4.0+ ships an engine-native FFI that works on Windows ARM64, so this is resolved by requiring Bun >= 1.4.0 there.

2. bun-pty ships only an x64 Windows DLL

bun-pty@0.4.8's Windows binary (rust_pty.dll) is x64-only and cannot be loaded by an arm64 process, breaking shell sessions via #pty. bun-pty is a Rust crate using the portable-pty backend and cross-compiles cleanly — it just needs a win32-arm64 build published (repo: github.com/sursaone/bun-pty).

Suggested fixes

• Document and/or enforce Bun >= 1.4.0 for windows-arm64 (CI matrix + docs).
• bun-pty: publish a windows-arm64 build, or have opencode vendor/swap the DLL for arm64 (the current local workaround does exactly this via a postinstall step).

Verified context

• Native single-file build (opencode-windows-arm64) succeeds with Bun 1.4.0 (arm64) on Windows 11 ARM64.
• Everything else in the toolchain (esbuild, tree-sitter, @opentui/core-win32-arm64, etc.) resolves for arm64 out of the box.

Happy to send the local patch (postinstall DLL swap + install script windows-arm64 combo) as a PR if useful.

[github-actions]

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

• Windows ARM64 native: OpenTUI fails to initialize with bun:ffi dlopen TinyCC error #19130: Windows ARM64 native: OpenTUI fails to initialize with bun:ffi dlopen TinyCC error (same bun:ffi/TinyCC error on Windows ARM64)
• OpenTUI fails to start on Windows ARM64: bun:ffi dlopen() is not available in this build #38520: OpenTUI fails to start on Windows ARM64: bun:ffi dlopen() is not available in this build (same root cause)
• Installer rejects windows-arm64 despite publishing that binary #44664: Installer rejects windows-arm64 despite publishing that binary (related Windows ARM64 support gap)
• [FEATURE]: Upgrade bundled Bun from 1.3.14 to 1.4.2 #44945: [FEATURE]: Upgrade bundled Bun from 1.3.14 to 1.4.0 (directly related to the Bun >= 1.4.0 requirement you mention)

Please check those threads to see if your issue is already being tracked or if there is useful context there. If your report covers something not addressed in those issues (particularly the bun-pty x64-only DLL for Windows ARM64), feel free to note that distinction.

[ataidecarlos]

Update: pre-existing PRs already cover both gaps — #44665 (install allowlist, by the issue author) and #44946 (Bun pin 1.4.0 + compatibility fixes, by the issue author). My PRs #45877/#45878 were closed as duplicates in favor of those. The remaining follow-up is the bun-pty x64-only Windows DLL (upstream: github.com/sursaone/bun-pty).

[dakehero]

The remaining native bun-pty piece is now proposed in sursaone/bun-pty#46.

It adds a separately named Windows ARM64 DLL, native ARM64 build/publish jobs, static CRT linkage, runtime selection with the existing x64 fallback preserved, and a bun build --compile ARM64 smoke test. I validated the ARM64 artifact locally on Windows 11 ARM64 with Bun 1.4.0: 86 unit tests and 11 integration tests pass, and the compiled executable runs successfully outside the repository.

Once released, this should complement #44665 and #44946 on the OpenCode side.