Copy/Paste and Remote Desktop Connection

Petra is the help-desk tooling dev at an insurance company where the entire claims-support team works inside an RDP session against a hardened Windows host. The agents read incoming email in Outlook on their local laptops and reply through a custom claims app -- powered by WinFormHtmlEditor -- running inside the RDP session. Their workflow is: select the relevant paragraph from the customer's email, copy, switch into the RDP window, paste into the claim note, edit, submit.

For the last month Petra has been chasing a ticket that, on paper, looks like an editor bug. Agents copy a formatted paragraph from Outlook -- bold, bullet points, a hyperlink -- and paste into the editor inside RDP, and the formatting evaporates. Sometimes only plain text arrives. Sometimes nothing arrives. The first instinct is to blame the editor. The actual cause is somewhere else entirely.

What Petra finds when she traces it

The editor reads pasted content through System.Windows.Forms.Clipboard, which calls the standard Win32 clipboard APIs. Inside an RDP session those APIs are serviced by rdpclip.exe, the clipboard proxy Microsoft ships with Remote Desktop Services. rdpclip.exe forwards plain text and a handful of well-known formats reliably, but it does not always negotiate the HTML clipboard format (CF_HTML) or custom rich formats correctly. When clipboard sharing is disabled in the RDP client settings, the proxy is not running at all -- in that case the local and remote clipboards are completely isolated and nothing transfers.

Petra confirms her theory by trying the same paste into a blank Word document running inside the same RDP session. Same outcome. Same dropped formatting. This is not an editor bug; it is a Remote Desktop clipboard limitation that affects every Windows application -- WinForms, WPF, native -- that uses the standard clipboard. She writes up an internal note and turns to fixes.

Fix 1: enable clipboard redirection in the RDP client

In mstsc.exe, open Show Options > Local Resources > Local devices and resources and confirm Clipboard is checked. Disconnect and reconnect -- rdpclip.exe launches on connect, so an existing session may need to be restarted. For Petra's team this is rolled out through Group Policy so the agents do not have to remember anything.

Fix 2: restart rdpclip mid-session when formatting drops

Some agents report that formatting works in the morning and stops working after lunch -- the clipboard channel sometimes wedges. Kill rdpclip.exe in Task Manager on the remote machine and relaunch it (Start > Run > rdpclip). The clipboard channel re-negotiates without dropping the session. Petra ships a small "Repair clipboard" button inside the claims app that runs the same restart for non-technical agents.

Fix 3: plain text fallback when fidelity matters less than getting the words in

For high-volume claim notes where the agent will reformat anyway, the team trains around copy-as-plain-text on the source side. Any HTML that does still land flows through the editor's built-in Word-paste cleanup, so formatted pastes that survive the channel still get sanitised.

What the editor cannot do

The editor sits on top of the standard Windows clipboard. It has no privileged path into rdpclip.exe, no way to coerce a disabled clipboard channel into working, and no way to detect with certainty that it is running inside an RDP session with broken redirection. If only plain text arrives on the clipboard, that is exactly what gets pasted; if nothing arrives, the paste is silently empty.

For applications that run primarily inside RDP or Citrix, the cleanest user experience is to make sure clipboard redirection is configured on the connection broker at deployment time rather than asking each end user to tick a box. That is how Petra closes the ticket -- not with an editor code change, but with a Group Policy update -- and the support volume drops off the next week.