[Bug] Clipboard write conflicts with Windows Terminal copy in RDP sessions

Status Open

Reported on v2.1.233

Maintainer reply None cached

Activity 6 comments · opened Aug 16, 2026

Bug Description
Windows: Claude Code rewrites the clipboard after the terminal has already copied, which breaks pasting into RDP sessions. Environment: Windows 11 Pro 26200.9168, Claude Code 2.1.233 (also reproduced on 2.1.232 and 2.1.228), Windows Terminal 1.24.11911.0 (copyOnSelect false), Windows PowerShell 5.1, mstsc to a Windows Server. Symptom: text selected and copied inside Claude Code cannot be pasted into an RDP session - the remote clipboard is left EMPTY, losing what was there before. Copying from an ordinary tab of the same Windows Terminal window works fine, so it is not the terminal, the RDP channel, the clipboard formats or the characters. Measured by polling GetClipboardSequenceNumber every 15 ms during one copy: 22:56:38.604 seq=335 owner=WindowsTerminal 708 B CF_UNICODETEXT, CF_LOCALE, CF_TEXT, CF_OEMTEXT 22:56:38.834 seq=346 owner=powershell 708 B + DataObject, Ole Private Data 22:56:38.880 seq=347 owner=NONE 708 B + DataObject, Ole Private Data 22:56:49.948 seq=352 owner=WindowsTerminal 370 B (plain dir copy, one state, pastes fine) Windows Terminal puts the selection on the clipboard first, in the ordinary form that crosses RDP. About 230 ms later a short-lived powershell.exe writes the same 708 bytes again with OLE formats on top, then exits. mstsc has already started transferring the first version to the server; the content is swapped underneath it, the transfer aborts, and the remote clipboard ends up empty. One write always works; two writes always fail. Workaround: hold Shift while selecting, so Windows Terminal owns the selection and Claude Code never performs its second write - then pasting into RDP works. Also fixable after the fact with: Set-Clipboard -Value (Get-Clipboard -Raw) Request: on Windows, skip Claude Code's own clipboard write when the terminal has already copied the selection, or make the second write optional.

Environment Info

Platform: win32
Terminal: null
Version: 2.1.232
Feedback ID: 24b73e48-6919-4642-ab26-b2bf8d649dab

Errors

[]

View original on GitHub ↗

3 Comments

doubleoh13 · 1 month ago

Still reproduces on 2.1.237 (Win 11 Pro 26200, WT 1.24.11911.0, copyFormatting: none). Two additions:

Remote side measured. Immediately after a Claude Code copy, on the RDP server [Windows.Forms.Clipboard]::GetDataObject().GetFormats($true) returns only Terminal Services Private Data — mstsc sends an empty format list, so the remote never learns text exists. After a Notepad or plain-WT-tab copy the same call shows UnicodeText.

Why the second write is harmful. The spawned helper is Windows PowerShell 5.1, whose Set-Clipboard uses WinForms → OleSetClipboard then OleFlushClipboard on exit. That's two clipboard states ~50 ms apart (owner=powershell with DataObject/Ole Private Data, then owner=none), landing ~200 ms after Windows Terminal's own clean Win32 write. pwsh 7's Set-Clipboard is a single Win32 SetClipboardData and crosses RDP fine — so even short of not double-writing, preferring pwsh or calling Win32 directly would avoid the race.

Also note this hits the client side (Claude Code on the laptop, pasting into mstsc sessions), not just session hosts. Shift+select (so WT owns the selection) confirmed as a workaround.

ondrejtucny · 1 month ago

Still reproduces on 2.1.241.

Text copied in Claude Code on Windows never reaches the RDP client — clipboard is set by a short-lived owner, breaking rdpclip synchronization

Environment

Claude Code: 2.1.241
OS (where Claude Code runs): Windows Server 2025 Datacenter 10.0.26100, inside a VM accessed via RDP with clipboard redirection enabled
Terminal: Windows Terminal 1.24.11321.0
Shell: PowerShell 7

Summary

When text is selected and copied inside Claude Code running full-screen (alternate screen buffer, mouse mode active — so Claude Code itself handles the selection/copy, not the terminal), the copied text can be pasted into any application inside the VM, but never arrives at the RDP client machine. Copying the very same text from Notepad or from a plain Windows Terminal selection syncs across RDP fine.

Steps to reproduce

Connect to a Windows VM via RDP with clipboard redirection enabled (rdpclip.exe running).
Run Claude Code in Windows Terminal, full screen.
Select a portion of the visible text and copy it (Claude Code performs the copy).
Paste inside the VM (e.g., Notepad) → works.
Paste on the RDP client machine → nothing / stale clipboard content.
Re-copy the same text from Notepad (or run Set-Clipboard (Get-Clipboard -Raw) in the VM) → pasting on the RDP client now works.

Reproducibility: 100%.

Diagnosis

The Win32 clipboard was inspected immediately after each kind of copy (enumerating raw formats via EnumClipboardFormats / GetClipboardData / GlobalSize, and querying GetClipboardOwner).

After the failing Claude Code copy

Owner: NULL (owner window gone, or clipboard set via OLE with no window)

Raw formats:
 49161  DataObject                          size=8 bytes
    13  CF_UNICODETEXT                      size=800 bytes
 49171  Ole Private Data                    size=168 bytes
    16  CF_LOCALE                           size=4 bytes
     1  CF_TEXT                             size=400 bytes
     7  CF_OEMTEXT                          size=400 bytes

After a working Windows Terminal selection copy (control)

Owner: HWND=... PID=... Process=WindowsTerminal

Raw formats:
    13  CF_UNICODETEXT                      size=292 bytes
    16  CF_LOCALE                           size=4 bytes
     1  CF_TEXT                             size=146 bytes
     7  CF_OEMTEXT                          size=146 bytes

Interpretation

The clipboard content is fine — plain CF_UNICODETEXT.
The failing copy carries DataObject + Ole Private Data formats and a NULL clipboard owner: the clipboard was set through the OLE clipboard (OleSetClipboard) by a process/window that was destroyed immediately afterward. This is the signature of a short-lived clipboard helper (as spawned, e.g., by the clipboardy npm package on Windows).
RDP clipboard redirection is a two-step handshake: on WM_CLIPBOARDUPDATE, rdpclip.exe announces the formats to the client, and the actual bytes are fetched from the clipboard owner later, on demand. Because the owner is already gone when rdpclip processes the update, the announce/fetch fails silently and the client never receives the data.
Inside the VM everything still pastes, because Windows force-renders all formats into global memory when the owner window is destroyed (WM_RENDERALLFORMATS) — local apps read that rendered data directly. Only the RDP boundary is affected.

Confirming experiment

Re-setting the byte-identical text from a live, persistent process:

Set-Clipboard (Get-Clipboard -Raw)

immediately makes the text pastable on the RDP client. Same data, different owner lifetime → the owner lifetime is the root cause.

Expected behavior

Text copied in Claude Code reaches the RDP client like text copied from any other Windows application.