opencode 1.18.25 (linux x64, Bun standalone): SIGILL (ud2 assertion) during initial TUI render via OpenTUI — parent and child processes die identically

Title: opencode 1.18.25 (linux x64, Bun standalone): SIGILL (ud2 assertion) during initial TUI render via OpenTUI — parent and child processes die identically

Environment

• opencode 1.18.25 installed via mise (~/.local/share/mise/installs/opencode/1.18.25/opencode), Bun standalone executable
• Arch Linux, kernel 7.1.9, glibc 2.44, AMD Ryzen 9 9900X, Hyprland/Wayland, launched from a terminal (xdg-terminal-exec scope)
• Model provider session (GLM via zai-coding-plan) — likely irrelevant to the render path

What happened

Launched opencode --auto --prompt "<long multi-line text>" (content elided — plain prose with newlines, nothing exotic). Approximately 8 seconds after launch, during initial TUI rendering, both opencode processes (parent PID 1761403 + child PID 1761503) crashed in the same second with identical stacks. No session had been created yet. systemd-coredump retained both cores.

Signal: 4 (ILL) si_code: ILL_ILLOPN

Forensics

Faulting instruction is a deliberate ud2 trap (preceded by call + int3 padding), at binary offset opencode + 0x2407064 — i.e., an assertion/panic in the Bun/Zig layer, not an unsupported CPU instruction and not memory corruption.

Both processes' stacks are byte-identical. Key frames (systemd unwinder):

#0-#3   opencode + 0x2407064 / 0x2405266 / 0x32dd8bf / 0x44e35ad   (trap + callers, Bun layer)
#4      libc.so.6 + 0x3e6f0
#5      /tmp/.<random-hash>-00000000.so + 0x1d061d

The /tmp/.<hash>-00000000.so module is OpenTUI core (extracted at startup, unstripped, full debug_info). Frame #5 symbolizes to:

buffer.OptimizedBuffer.trySetTransparentTextCellFast
opentui/packages/core/src/zig/buffer.zig:896 (discriminator 6)

So the crash thread was rendering text cells into the TUI buffer during startup when the Bun layer hit an internal assertion.

Recurrence

First occurrence after ~50 sessions across 5 days on 1.18.25 (installed 2026-09-01; zero prior opencode coredumps on this machine). Immediate relaunch with the same command succeeded and ran normally. One-off so far, but both processes dying simultaneously at the same assertion suggests a startup-render race rather than content-dependent input.

Questions / offers

• Is +0x2407064 (1.18.25 linux x64 build) a known Bun-side assertion site reachable from the OpenTUI render path? If you can symbolize internally, the full coredumpctl stacks of both PIDs are available on request (they are 99 MB each — not attached).
• Any known startup-render race between parent and child both initializing the TUI buffer (transparent-cell fast path)?
• Happy to re-run with any diagnostic build or env var you suggest.