Describe the bug

When using opencode on macOS with OrbStack (which mounts an NFS share at ~/OrbStack), macOS kernel NFS status messages appear in the opencode TUI even when opencode is completely idle (no commands running, no user input).

These messages look like:

nfs server OrbStack:/OrbStack: resource temporarily unavailable (jukebox)
nfs server OrbStack:/OrbStack: not responding
nfs server OrbStack:/OrbStack: is alive again
nfs server OrbStack:/OrbStack: resource available again

They:

• Corrupt the TUI display by painting raw text into the input area and other UI regions
• Input still works, but the display is visibly broken with garbage text overlaid on the TUI
• Can be recovered by triggering a TUI repaint (e.g., Ctrl+P to open the command palette)

Why this is different from existing issues

Related but distinct from:

• Background hook stderr output can be painted into the input box until terminal repaint #31219 — opencode's own hooks writing to stderr
• console.trace in fn.ts corrupts TUI display on schema validation failure #16841 — console.trace() corrupting TUI
• Random hexadecimal characters in chat input #16511 — random hex characters in input
• [BUG] Garbled ANSI escape sequences and plugin connection failure with agentmemory #24206 — garbled ANSI sequences from plugins

These existing issues are all about opencode's own code/plugins producing unexpected output.

This issue is about external kernel messages from the macOS NFS subsystem that bypass all application-level logging (os_log, syslog, stderr) and get written directly to the process's terminal file descriptor via the kernel's ttyprintf() mechanism. No opencode process is responsible for generating this output — it arrives asynchronously from the kernel.

How to reproduce

1. Use macOS with OrbStack (which mounts an NFS share at ~/OrbStack)
2. OrbStack's NFS server experiences momentary instability (OrbStack has known NFS reliability issues: orbstack#2502, orbstack#2347)
3. Open opencode, leave it idle — do NOT run any commands
4. Within minutes to hours, kernel NFS messages leak into the TUI and corrupt the display
5. Display can be recovered via Ctrl+P (or any action that triggers a full TUI repaint), but returns when the next kernel NFS message arrives

Technical context

On macOS, when an NFS server becomes unresponsive, the kernel NFS client writes status messages:

1. NOT through os_log (zero entries in log show)
2. NOT through syslog (zero entries in /var/log/system.log)
3. NOT associated with any running process — appears even when terminal is idle
4. There is no macOS configuration to suppress these kernel messages (verified against sysctl, nfs.conf(5), and /etc/asl.conf)

The only defense is for the TUI application itself to handle unexpected terminal writes gracefully.

Expected behavior

opencode's TUI should be resilient to unexpected terminal output from external sources (kernel, background daemons, etc.). Ideally:

• Filter/ignore such output, OR
• Recover via repaint on the next TUI event (e.g., on each keypress or via a periodic refresh)

Environment

• opencode: v1.17.9
• macOS: 26.5 (Sequoia)
• Machine: Mac Mini (Apple Silicon, no sleep)
• OrbStack: v2.2.1
• Terminal: Cursor / iTerm2