Fullscreen TUI copies never reach the RDP/AVD client clipboard: spawned Set-Clipboard helper exits before the AVD clipboard broker samples the update

Summary

On an Azure Virtual Desktop (AVD) session host, text copied inside the Claude Code fullscreen TUI lands on the session host's clipboard (pastes fine into apps on the host) but never propagates to the connecting client's local clipboard, while copies made from any GUI app on the same host (Chrome, Word, Notepad) propagate immediately.

Root cause analysis (details below): on native Windows, Claude Code copies by spawning a PowerShell helper that runs Set-Clipboard and exits immediately. AVD's current clipboard broker (rdpclipcdv.exe, the "SxS RDP Clipboard Monitor" that replaces rdpclip.exe on SxS stacks >= 1.0.2501.05600) samples the clipboard and interacts with the owning process roughly 200-300 ms after the copy. By then Claude Code's helper is dead, and the update is never forwarded to the client (no CLIPRDR Format List is sent), so the client keeps its stale clipboard. Long-lived GUI owners never lose this race, which exactly matches the observed app-selective behavior.

For users on managed VDI (a growing share of enterprise/government development environments), this makes every copy out of Claude Code a multi-step ritual.

Environment

| Item | Value |
|---|---|
| Claude Code | 2.1.225 (native Windows build), "tui": "fullscreen" |
| OS (session host) | Windows 11 Enterprise multi-session 10.0.22631, Azure Virtual Desktop |
| AVD SxS stack | RDInfra rdr_sxs 1.0.2606.09020; session clipboard broker = rdpclipcdv.exe ("SxS RDP Clipboard Monitor"); classic rdpclip.exe absent by design on stacks >= 1.0.2501.05600 |
| Terminal | Windows Terminal 1.24.11911.0 (Windows 11 default-terminal delegation), Windows PowerShell 5.1 shell |
| Client | Native Windows AVD client on a physical machine, clipboard redirection enabled and working for GUI apps |

Symptom

1. Select text in the Claude Code fullscreen TUI (copy-on-select or Ctrl+Shift+C). Claude Code reports the copy; pasting inside the remote session works, so the text is on the host clipboard.
2. Paste on the local client machine: old/stale clipboard content. The copy never crossed.
3. Copy anything from a GUI app in the same session: crosses to the client instantly.
4. Deterministic workaround: paste the text into any GUI app on the host and re-copy it there - it then crosses. Scripted equivalent that also works: Get-Clipboard -Raw | Set-Clipboard in a live interactive PowerShell window.

Investigation evidence (collected live on the affected host)

1. Claude Code's Windows copy mechanism (strings extracted from the shipped claude.exe): it spawns PowerShell running [Console]::InputEncoding = [Text.Encoding]::UTF8; Set-Clipboard -Value ([Console]::In.ReadToEnd()) with the text piped via stdin. The helper process exits immediately after writing, so the Win32 clipboard owner is a dead process within milliseconds of the copy. (An OSC 52 path - ]52;c; - also exists in the binary for remote/tmux scenarios; it is not what fires in this environment.)
2. The RDP clipboard channel is healthy: cliprdr shows as connected in the RdpCoreCDV operational event log; host-side policies are clean (fDisableClip=0, no SCClipLevel/CSClipLevel restrictions, no DLP or clipboard-manager software running).
3. Format filtering is ruled out: failing (Claude Code) and succeeding (browser address bar) copies carry the same plain-text format set (CF_UNICODETEXT + synthesized conversions).
4. Delayed rendering is ruled out, and broker timing was measured: a probe window that placed a delayed-render CF_UNICODETEXT promise and stayed alive received the broker's WM_RENDERFORMAT pull ~230 ms after the copy. The broker handles even delayed content fine - when the owner is still alive to answer. That measured post-copy sampling delay is the race Claude Code's exit-immediately helper loses deterministically.
5. Protocol detail explaining the "silently stale" client clipboard: CLIPRDR only sends a Format List announcement at copy time (data crosses on paste). Failing copies never generate that announcement, so the client is never told the clipboard changed.

The one link not directly observable from the host is rdpclipcdv's internal drop decision (its internals are unpublished); dead-owner-at-sampling-time is the only hypothesis consistent with all of the above.

Steps to reproduce

1. AVD session host on a current SxS stack (check: rdpclipcdv.exe running in the session, rdpclip.exe absent). Connect from a Windows client with clipboard redirection enabled.
2. Run claude with the fullscreen TUI in Windows Terminal.
3. Select and copy text inside the TUI.
4. Paste inside the session: works. Paste on the local client: stale content.
5. Run Get-Clipboard -Raw | Set-Clipboard in an interactive PowerShell in the session: the same text now reaches the client.

Suggested fixes

Any of these would close the race:

1. Keep the clipboard helper alive briefly (1-2 s) after Set-Clipboard returns, so session clipboard brokers (AVD rdpclipcdv, classic rdpclip, clipboard history, DLP monitors) can sample while the owner process still exists. Cheap and low-risk; could be gated on remote sessions (GetSystemMetrics(SM_REMOTESESSION) or SESSIONNAME starting with RDP-/rdp-sxs).
2. Write the clipboard from the persistent CLI process (or a kept-alive helper) instead of a throwaway child, so the clipboard owner remains alive for the lifetime of the copy.
3. Optionally also emit OSC 52 on terminals that support it, which sidesteps host-side brokers entirely.

Workarounds for affected users (until fixed)

• After copying in the TUI, run Get-Clipboard -Raw | Set-Clipboard in any live PowerShell window (aliasable to a two-letter function).
• Hold Shift while drag-selecting to bypass the TUI's mouse capture and use the terminal's native copy (long-lived owner), then the terminal's copy key.
• Paste into any GUI app on the host and re-copy.

Related

Possibly the same underlying defect as #72617 ("Copying text from the Claude Code terminal UI doesn't reach the system clipboard (Windows 10)") - any clipboard consumer that samples after the helper exits (redirection brokers, history, monitors) would see the same race; this report adds a measured 230 ms broker sampling delay and a fully evidenced AVD/RDP manifestation.