tui: TUI freezes on Ctrl+V paste over SSH (Windows); clipboard read appears to hang #55775

Description

Summary

Pasting into the OpenCode TUI with Ctrl+V freezes the UI indefinitely when OpenCode runs on a remote Windows host over SSH (Windows Terminal is the client). The process stays alive at ~0% CPU and must be killed. The pasted bytes arrive intact (bracketed paste is complete), so the transport is not the cause; the hang appears to be in the TUI's native clipboard read path.

Environment

• opencode version: 2.0.24 (npm global @opencode/cli; latest on npm at report time: 2.0.29)
• OS: Windows 11 Pro, Build 26300 (x64) on the client; the remote host is also Windows (10.0.26300)
• Terminal: Windows Terminal 1.24.12741.0 (WT_SESSION set), TERM=xterm-256color
• Shell: cmd.exe on the remote host (COMSPEC=C:\WINDOWS\system32\cmd.exe)
• Install/channel: latest (npm global)
• Remote transport: OpenSSH_for_Windows_9.5p2 (sshd on the remote Windows host)

Reproduction

1. From Windows Terminal, SSH into a remote Windows host and start OpenCode (TUI).
2. On the local machine, copy a URL from a browser address bar.
3. Focus the OpenCode prompt and press Ctrl+V.
4. The TUI freezes (no redraw, no response to keys); the process stays alive at ~0% CPU and has to be killed.

Variations observed:

• Same freeze when pasting via Win+V (Windows clipboard history).
• No freeze when the same-length text is copied from Notepad instead of the browser.
• No freeze when OpenCode runs locally (no SSH) and the same browser URL is pasted.

Expected Behavior

The pasted text appears in the prompt and the TUI stays responsive.

Actual Behavior

The TUI becomes completely unresponsive and stays hung until killed. No error is shown, and nothing is written to the OpenCode log at the moment of the freeze.

Additional Context

Transport is fine (rules out a Windows Terminal bracketed-paste problem): a raw-mode probe over SSH captured exactly ESC[200~ + <url> + ESC[201~ in a single read (a 6-byte start marker, then the text together with the end marker). The bracketed paste is delivered intact.

Points at a native clipboard read hang:

• The v2 binary (@opencode/cli 2.0.24) contains clipboard-provider strings: Clipboard read timed out, Clipboard content exceeded configured read or image conversion limits, Unexpected clipboard MIME type:, preferredTypes, all-available, getClipboardText, hasClipboardImage, useClipboard must be used within a ClipboardProvider, plus Win32/COM imports OpenClipboard, GetClipboardData, GetClipboardSequenceNumber, IsClipboardFormatAvailable, CoInitializeEx, CoCreateInstance.
• During the freeze the OpenCode process shows ~0% CPU over a 2 s sample (blocked, not busy-looping) with a ~200 MB working set.
• The log shows no clipboard/paste/error entries at the freeze time, i.e. the hang is below the JS server layer.
• This matches the reported regression where a single clipboard-read timeout wedges every later paste: tui: all pastes hang after one clipboard read timeout (Linux/Wayland) #50847 (tui: pasting a few KB of text renders the whole paste and hangs #52422 was auto-linked to it).

Why the clipboard read can block here: the clipboard is read on paste. Over SSH the TUI runs on the remote host, where that read can block/time out; per #50847 the failed read is never reset, so every subsequent paste also hangs.

What does not reproduce: feeding the exact same bracketed-paste bytes (URL / empty body / 5 KB of text / 200 lines) into an OpenCode TUI over a local sshd on the same machine does not hang; the TUI stays responsive and large pastes collapse to a placeholder. The freeze needs the real interactive terminal/clipboard environment.

Candidate deterministic repro (not yet verified by the reporter): hold the Win32 clipboard open in another process for ~60 s (OpenClipboard without CloseClipboard), then press Ctrl+V in OpenCode; a blocked clipboard read should reproduce the hang.

Workarounds: none help consistently; only restarting OpenCode clears the stuck state.

Plugins

No response

OpenCode version

No response

Steps to reproduce

No response

Screenshot and/or share link

No response

Operating System

No response

Terminal

No response