[Windows] TUI copy blanks the RDP host clipboard: PowerShell 5.1 `Set-Clipboard` overwrites the OSC 52 write
Environment
- Claude Code 2.1.296, Windows 11 Pro 10.0.26300
- Windows Terminal Preview 1.25.1912.0
- Claude Code running inside a Remote Desktop session (client: RDCMan / mstscax on the host)
Symptom
Selecting text with the mouse in the fullscreen TUI copies it within the remote session, but pasting on the RDP host gives an empty clipboard. A native Windows Terminal copy (Shift+drag) and a plain Set-Clipboard from pwsh 7 both reach the host.
Cause
On windows, setClipboard emits OSC 52 and also runs, unless SSH is detected:
powershell -NoProfile -NonInteractive -Command "[Console]::InputEncoding = [Text.Encoding]::UTF8; Set-Clipboard -Value ([Console]::In.ReadToEnd())"
Clipboard sequence log for one TUI copy:
10:36:44.151 owner=WindowsTerminal fmts=13,16,1,7 <- OSC 52
10:36:44.400 owner=- fmts=49161(DataObject),13,49171(Ole Private Data),16,1,7 <- powershell.exe Set-Clipboard
Windows PowerShell 5.1 Set-Clipboard writes through the OLE clipboard (WinForms), and the process exits immediately. The second write replaces the good Windows Terminal write. rdpclip announces the new formats to the RDP client. The host clipboard then comes up empty, most likely because the host fetches the data lazily after the short-lived writer process has exited (not yet isolated from a race between the two writes 250 ms apart).
Side effect outside RDP: each TUI copy creates two Win+V clipboard-history entries.
Repro
- RDP into a Windows machine and run
claudein Windows Terminal. - Select text with the mouse in the TUI.
- Paste on the RDP host: the clipboard is empty.
Suggested fixes
- Skip the native write when the terminal handles OSC 52 (Windows Terminal:
WT_SESSIONis set), or - Write with Win32
OpenClipboard/SetClipboardData(CF_UNICODETEXT)(or pwsh 7'sSet-Clipboard, which does this) instead of Windows PowerShell 5.1, or - Provide a setting/env var to disable the native clipboard write.