Problem

Clipboard copy operations (e.g., Ctrl+X Y to copy assistant message) silently fail when running opencode over SSH or in tmux on a remote Linux server without X11/Wayland display.

Root cause: The fallback path uses clipboardy, which relies on xsel/xclip and requires a local display ($DISPLAY or $WAYLAND_DISPLAY). In headless SSH/tmux environments, these tools aren't available or don't work, causing clipboard operations to fail silently.

Solution

Add OSC 52 escape sequence support as a fallback when clipboardy fails.
OSC 52 is a terminal escape sequence standard that allows applications to set the system clipboard through the terminal emulator. It's supported by:

• iTerm2
• kitty
• Alacritty
• Windows Terminal
• tmux (with set-clipboard option)
• Many other modern terminal emulators

Changes

• Added copyViaOSC52() function that sends OSC 52 escape sequences
• Handles tmux passthrough wrapping when $TMUX is set
• Modified fallback logic: try clipboardy first → fall back to OSC 52 on failure

Behavior

No breaking changes - existing behavior preserved for all native clipboard methods.

Testing

1. SSH into a remote Linux server
2. Run opencode in tmux with iTerm2 integration
3. Get a response from the assistant
4. Press Ctrl+X Y to copy the assistant's message
5. Cmd+V on local machine to verify clipboard content

Prerequisite

• Enable "Applications in terminal may access clipboard" in iTerm2 Preferences → General → Selection