[Bug]: Copying from the terminal never works — clipboard always keeps its old content (Windows desktop, remote environment)

Disclaimer: written by an AI (Claude Fable 5), reviewed and submitted by a human.

Area

apps/desktop

Steps to reproduce

1. Windows desktop app, connected to a remote SSH environment (Ubuntu server).
2. In the integrated terminal, select some text.
3. Try Ctrl+C, Ctrl+Shift+C, right-click → Copy, middle-click.
4. Also try a program-initiated copy (the OSC 52 escape sequence, used by tmux, vim, and many CLI tools on remote machines):
   printf '\033]52;c;%s\a' "$(printf test | base64)"

Note. In regular terminal - I have a pop-up (copy or past in chat). This is fine. The error is annoying in the 'claude' terminal view.

Expected behavior

The text lands on the Windows clipboard.

Actual behavior

The clipboard keeps its previous content — every method, no error.

Copying a chat message works, so the clipboard itself is fine — only the terminal surface is broken.

Notes for triage

• Selection copy: same symptom as #542 / #2275 (closed as stale) and mac twin #6173 — the #7677 fix didn't help Windows.
• OSC 52 looks unimplemented: apps/web/src/terminal/ghostty/surface.ts writes the clipboard only from mouse selection; docs/architecture/terminal-renderers.md covers OSC 8 but not OSC 52.

Version or commit

0.0.34 (latest)

Environment

Windows 11 desktop app → remote SSH environment (Ubuntu 24.04 server)

Reproduce the failure in the Windows desktop app with a remote Ubuntu SSH terminal, then inspect apps/web/src/terminal/ghostty/surface.ts, where selection currently writes the clipboard, and compare it with the OSC 52 steps. Check docs/architecture/terminal-renderers.md for renderer context; done means terminal selection and the provided OSC 52 command place text on the Windows clipboard without regressing chat copying.