feat: forward application OSC 52 clipboard writes through boo ui

[kylecarbs]

Problem

boo ui renders each session from a client-side libghostty terminal and repaints the viewport from its state, rather than passing session output through raw (see the ui.zig header). libghostty-vt parses OSC 52 but exposes no clipboard effect, so when an application inside a session copies text itself (an editor yank, a mouse-driven TUI's selection, anything emitting ESC ] 52 ; c ; <base64> BEL), the sequence is parsed and dropped. The copy never reaches the user's clipboard, even over SSH.

This is specific to boo ui:

• boo ui's own mouse selection already copies via OSC 52 (copySelection), but only when the focused app has not grabbed the mouse.
• When a TUI enables mouse reporting, boo ui forwards the mouse to the app, the app does its own copy, and that OSC 52 is swallowed.
• Plain boo attach is raw passthrough and already forwards an app's OSC 52 unchanged.

Fix

Add src/osc52.zig: a split-safe incremental scanner (modeled on oscquery.zig) that recognizes OSC 52 clipboard writes in a byte stream. The focused View runs it over session output in feedOutput and forwards each complete write verbatim to the real terminal (fd 1), the same destination as copySelection, before the view-canvas parses and drops it.

Only writes are forwarded. A read request (ESC ] 52 ; c ; ? ST) asks the terminal to hand the clipboard back to the application; forwarding it would let a remote session read the user's local clipboard, so a ? payload is recognized and ignored. Oversized writes (over 2 MiB) are dropped rather than buffered without bound.

Test plan

• New unit tests in src/osc52.zig: BEL and ST terminators, read-request rejection, empty/clear payloads, split-across-feeds, OSC 520 and other-OSC near-misses, back-to-back writes, and a long under-cap payload.
• New integration test ui: an application's own OSC 52 clipboard write reaches the real terminal. Confirmed it fails with timeout: waiting for output when the feedOutput forwarding line is removed, and passes with it.
• zig build test-all (163 unit + 81 integration) and zig build test-all -Doptimize=ReleaseSafe: 244/244 pass. zig fmt --check clean.

Decision log

• Where to fix. The daemon already forwards OSC 52 to the attached client; neither oscquery.Filter (OSC 11 queries) nor altscreen.Filter (screen toggles) strips it. The loss happens in the boo ui client, where feedOutput pipes bytes into the clipboard-less view-canvas. So the fix is client-side, in View.
• Why a byte-level scanner, not a libghostty effect. libghostty-vt's effect set (write_pty, bell, color_scheme, device_attributes, enquiry, size, title/pwd, xtversion) has no clipboard callback, so there is nothing to hook. A small passthrough filter matches how OSC 11 and alt-screen toggles are already handled.
• Forward verbatim. The exact bytes the app emitted are re-emitted, so the user's terminal sees the app's intent with no re-encoding. The terminal still gates whether OSC 52 writes are honored, exactly as for a plain boo attach.
• Security. Read requests are intentionally not forwarded, so a remote session cannot exfiltrate the local clipboard.
• Split safety. protocol.max_payload is 1 MiB, so a clipboard write can span multiple .output frames; the scanner carries candidate state across feeds.

---

Opened by Coder Agents on behalf of @kylecarbs.