[FEATURE]:TUI crashes with STATUS_ACCESS_VIOLATION (0xC0000005) during terminal capability negotiation on Windows on ARM (Snapdragon X Elite) #41094

Feature hasn't been suggested before.

• I have verified this feature I'm about to request hasn't been suggested before.

Describe the enhancement you want to request

Environment

• Device: Windows 11 on ARM, Snapdragon(R) X Elite - X1E78100 (Qualcomm Oryon)
• [System.Runtime.InteropServices.RuntimeInformation]::OSArchitecture → Arm64
• Node.js (via Volta): native ARM64 build, process.arch → arm64
• opencode binary used: opencode-windows-x64 (native opencode-windows-arm64 build crashes separately/differently, likely due to the known TinyCC/bun:ffi JIT issue on ARM64 — the x64 build runs fine standalone under Windows' x64 emulation for --version / opencode run, but not for the TUI, see below)

Versions tested (both crash identically)

• opencode-ai 1.18.15 / opencode-windows-x64 1.18.15
• opencode-ai 1.17.9 / opencode-windows-x64 1.17.9 (downgraded specifically because OpenCode v1.17.10 crashes with Bun segmentation fault on Windows; v1.17.9 appears stable #33742 reported 1.17.9 as "stable" — did not help for this crash)

Terminals tested (all crash identically)

• Antigravity IDE integrated terminal
• Classic PowerShell console host (conhost)
• Genuine Windows Terminal app, multiple profiles: Windows PowerShell, Developer Command Prompt for VS 2022, Developer PowerShell for VS 2022

Other things ruled out

• Not a git-bash PTY spawn issue (unlike Windows Terminal: Git bash.exe causes ACCESS_VIOLATION crash (0xC0000005) #11954): set "shell" in both project and global opencode.json to powershell.exe explicitly — no change.
• Not a Windows Defender DLL-block issue (unlike Windows Security blocks OpenTUI DLL during opencode initialization: Error Code 4551 #21234): added Defender path exclusions for %TEMP%, the opencode install/bin directories — no change. (Also our crash happens after the OpenTUI render library has already initialized and started sending escape sequences, whereas Windows Security blocks OpenTUI DLL during opencode initialization: Error Code 4551 #21234 fails to initialize the library at all with a distinct visible error message — different failure mode.)
• Not a stale/wrong-architecture binary issue: verified via SHA-256 that the exact same opencode-windows-x64 binary is used everywhere on PATH; opencode --version and opencode run "..." both work reliably and repeatedly with this binary.

Steps to reproduce

1. On a Windows-on-ARM machine, install opencode (npm install -g opencode-ai), running under opencode-windows-x64 (x64 build, since the native ARM64 build fails to start at all).
2. Run opencode (bare, no args) from any terminal.
3. It silently returns to the shell prompt after ~1-2 seconds. No visible error text. Leftover raw escape sequence fragments (e.g. ^[[O^[[I, stray [) are sometimes left printed at the next prompt, consistent with the process dying before it could restore terminal modes (it had enabled focus-event reporting / alternate screen before crashing).

Actual behavior
echo $LASTEXITCODE after the crash: -1073741819 (0xC0000005 / STATUS_ACCESS_VIOLATION).

Captured via opencode --print-logs --log-level DEBUG > log.txt 2>&1, the log shows the crash happens immediately after "applying tui config", while the following escape sequences are being sent (terminal capability negotiation / alternate screen entry):

[?2031h ]10;? ]11;? [>0q [?25l [s [6n [?1016$p [?2027$p [?2031$p [?1004$p [?2004$p [?2026$p [?u ]99;i=opentui-notifications:p=?; ]1337;Capabilities [H ]66;w=1; [6n [H ]66;s=2; [u [s [?1049h [>4;1m [?2027h [?2004h [14t

The process dies right around/after [?1049h (enter alternate screen) and [14t (report window size in pixels — not supported by classic Windows consoles, possibly related). Nothing further is logged; no exception, no stack trace, no OpenTUI error — just the raw OS-level access violation.

Expected behavior
The TUI should launch normally (as it does, presumably, on x64-native Windows).

Workaround found
opencode run "<message>" (non-interactive, no alternate-screen TUI) works reliably and repeatedly — confirmed across multiple runs, correctly picks up project config/model. So this appears isolated specifically to the OpenTUI full-screen renderer's Windows console capability-negotiation code path, not to opencode/Bun generally on this machine.

Hypothesis
Given this is a Windows-on-ARM device, and the crash is specifically located in native console-capability-query/response handling code that behaves fine when the same x64 binary runs on native x64 Windows, this may be a bug in how OpenTUI's native (Zig, via bun:ffi) console I/O code behaves when the process itself is running under Windows' x64-on-ARM emulation (Prism/xtajit) — e.g. a race condition or unexpected response format/timing when reading back the terminal's response to a DSR/capability query through the emulation layer, causing an out-of-bounds read in the native parser.

Happy to provide more logs / test patches if useful — this exact crash is 100% reproducible on this machine.