Copy/Paste and Remote Desktop Connection (WPF)
A common deployment pattern runs an entire support or claims-processing team inside a Remote Desktop session against a hardened Windows host, using a custom application built on WpfHtmlEditor. Agents read incoming content locally, for example in Outlook on their own machine, then switch into the RDP window and paste it into the editor to continue their work.
When that paste carries formatting, bold text, bullet points, a hyperlink, the formatting can be lost: sometimes only plain text lands, sometimes nothing lands at all. The first instinct is to treat this as an editor defect. The actual cause sits below the editor, in the Remote Desktop clipboard channel itself, and it is identical to the limitation documented for the WinForms edition because both host the same MSHTML engine and both sit downstream of the same Windows clipboard.
Root cause: the RDP clipboard proxy, not the editor
The editor reads pasted content through System.Windows.Clipboard, the WPF clipboard API (wrapped internally by the control's IClipboard adapter). Inside an RDP session that API is serviced by rdpclip.exe, the clipboard proxy Remote Desktop Services installs on the remote machine. 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 other rich formats correctly. When clipboard sharing is turned off in the RDP client's connection settings, the proxy never runs at all, so the local and remote clipboards stay completely isolated and nothing transfers.
Confirm this independently of the editor by pasting the same formatted content into a blank WordPad or Word document inside the same RDP session; the formatting drops there too. This is a Remote Desktop clipboard limitation that affects every Windows application, WPF, WinForms, native, that reads the standard clipboard. It is not specific to WpfHtmlEditor, and switching to the WinForms edition of the control would not change it either; both editions host the same MSHTML rendering engine and both sit on top of the same OS clipboard mechanism.
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 already-open session may need to be restarted. Roll this out through Group Policy for a team of any size, rather than relying on each user to set it individually.
Fix 2: restart rdpclip mid-session; fix 3: plain-text fallback
Some users report that formatting pastes correctly earlier in the day and stops working later in the same session, the clipboard channel can wedge over time. 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. A small "Repair clipboard" command inside your own application, wired to the same restart, saves a non-technical user a trip to Task Manager.
For high-volume workflows where the user will reformat content anyway, train around copy-as-plain-text on the source side. Any HTML that does survive the channel still flows through the editor's built-in Word-paste cleanup (Options.AutoDetectWordPaste), so a formatted paste that lands gets sanitized the same way it would outside of RDP.
Detecting a failed paste with the Pasting event
The Pasting event fires before the incoming HTML is inserted, and its PastingHtmlEventArgs.PastingHtml property lets you see exactly what arrived. An empty payload that is not an MS Word paste is a strong signal the clipboard channel dropped the content, which is a better moment to nudge the user than letting them discover a blank paste on their own:
// Wire this to the editor's Pasting event (XAML: Pasting="NoteEditor_Pasting").
private void NoteEditor_Pasting(object sender, PastingHtmlEventArgs e)
{
if (string.IsNullOrEmpty(e.PastingHtml) && !e.IsPastingFromMsWord)
{
// Nothing arrived on the clipboard: likely a broken RDP redirection.
MessageBox.Show("Nothing was found on the clipboard. If you are working over " +
"Remote Desktop, ask your administrator to restart rdpclip.exe on the remote machine.");
}
}' Wire this to the editor's Pasting event (XAML: Pasting="NoteEditor_Pasting").
Private Sub NoteEditor_Pasting(sender As Object, e As PastingHtmlEventArgs)
If String.IsNullOrEmpty(e.PastingHtml) AndAlso Not e.IsPastingFromMsWord Then
' Nothing arrived on the clipboard: likely a broken RDP redirection.
MessageBox.Show("Nothing was found on the clipboard. If you are working over " &
"Remote Desktop, ask your administrator to restart rdpclip.exe on the remote machine.")
End If
End SubWhat the editor cannot do
The editor sits on top of the standard WPF clipboard. It has no privileged path into rdpclip.exe, no way to force a disabled clipboard channel to work, and no reliable 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. The Pasting handler above can flag the empty case, but it cannot make a missing clipboard format arrive.
For applications that run primarily inside RDP or Citrix, the cleanest approach 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 a Group Policy or connection-broker setting, not an editor code change.
Ask your AI to do this
Let your assistant do this for you. With the SpiceLogic MCP server connected, paste this into Claude Code, Cursor, or VS Code Copilot in agent mode.
Using the SpiceLogic WPF HTML Editor already referenced in my project, my support agents work inside an RDP session and their pastes from Outlook into the WpfHtmlEditor control keep arriving as plain text or empty, so add a Repair clipboard command to my claims app that restarts rdpclip.exe on the remote machine, and wire a Pasting event handler on the editor that warns the user when PastingHtmlEventArgs.PastingHtml is empty and it is not an MS Word paste, so they know to retry. Confirm the editor's built-in Word-paste cleanup (Options.AutoDetectWordPaste) still sanitizes any HTML that does make it across the clipboard. Check the SpiceLogic MCP tools for the current WpfHtmlEditor API surface before writing any code.