Problem Statement
Tools running on the remote host (tmux set-clipboard, vim/neovim OSC 52 clipboard providers, etc.) cannot put text on the user's local system clipboard across an SSH session. Today the only ways to get remote text onto the local clipboard are a mouse selection or an SFTP round-trip. Power users who rely on yank-to-clipboard in tmux/vim expect OSC 52 to "just work".
Proposed Solution
Support the OSC 52 escape sequence (ESC ] 52 ; Pc ; Pd ST) so a remote app can write the local clipboard.
- Write only. The read side (
OSC 52 ; c ; ?, which asks the terminal to report the local clipboard back to the remote) is deliberately not implemented — it would let a remote server exfiltrate clipboard contents (passwords, tokens). This matches the safe default of most terminals.
- Per-host opt-in, default off. A remote that can write the clipboard can stage a paste-injection, so the feature is gated behind a per-host toggle that defaults off (mirrors the existing Agent forwarding opt-in).
- Decoded payload capped at 1 MiB; invalid/oversized payloads are dropped fail-soft.
Alternatives Considered
- Mouse selection / SFTP transfer — the current workarounds; slow and break the keyboard-only flow.
- A global toggle instead of per-host — rejected for now; per-host opt-in is the right safety granularity.
Additional Context
OSC 52 already surfaces in the app as Terminal.onPrivateOSC('52', [...]), so the write path needs no xterm core change — routing happens in the app layer next to the existing OSC 7/133 (shell integration) handling. Cross-platform (macOS / Windows / Linux) via Flutter's Clipboard.
Design: docs/superpowers/specs/2026-06-14-osc52-clipboard-design.md
Problem Statement
Tools running on the remote host (tmux
set-clipboard, vim/neovim OSC 52 clipboard providers, etc.) cannot put text on the user's local system clipboard across an SSH session. Today the only ways to get remote text onto the local clipboard are a mouse selection or an SFTP round-trip. Power users who rely on yank-to-clipboard in tmux/vim expectOSC 52to "just work".Proposed Solution
Support the
OSC 52escape sequence (ESC ] 52 ; Pc ; Pd ST) so a remote app can write the local clipboard.OSC 52 ; c ; ?, which asks the terminal to report the local clipboard back to the remote) is deliberately not implemented — it would let a remote server exfiltrate clipboard contents (passwords, tokens). This matches the safe default of most terminals.Alternatives Considered
Additional Context
OSC 52 already surfaces in the app as
Terminal.onPrivateOSC('52', [...]), so the write path needs no xterm core change — routing happens in the app layer next to the existing OSC 7/133 (shell integration) handling. Cross-platform (macOS / Windows / Linux) via Flutter'sClipboard.Design:
docs/superpowers/specs/2026-06-14-osc52-clipboard-design.md