Set-Clipboard -Remote with OSC52

Summary of the new feature / enhancement

Set-Clipboard does not really work over SSH, as it always sets the clipboard of the target machine, not the host. This means that if you SSH e.g. from your PC to a server, then Set-Clipboard will set the server’s clipboard, not your PCs, so you cannot paste it anywhere.

This can be resolved by using ANSI escape sequence (same mechanism as for setting colors) OSC52, which sets the clipboard of the host machine, which in our example is the PC, so you can paste it anywhere. This sequence is supported by most terminals, including Microsoft Terminal.

Example:

function Set-RemoteClipboard($text) {
    Write-Host "`e]52;;$([System.Convert]::ToBase64String([System.Text.Encoding]::UTF8.GetBytes($text)))`a"
}
# Copy "original" into a clipboard from anywhere
> Set-Clipboard 'changed'
# Press Ctrl+Shift+V to see clipboard still "original"
> Set-RemoteClipboard 'changed'
# Press Ctrl+Shift+V to see clipboard now "changed"

OSC also has similar Get-Clipboard -Remote sequence, but no terminal implements it as it is rightly considered a security and privacy risk, and you ca simply “get” the host clipboard with Ctrl+Shift+V.

Opens:

1. Should we autodetect when to use the OSC52 instead of xclip or other OS target-implementation? E.g. SSH can be detected by presence of environment variables $env:SSH_CLIENT and $env:SSH_TTY. I would say no, as it could be potentially breaking behavior in case of false positives on terminals which don’t support the OSC. If user wants such behavior, they can add $PSDefaultParameters['Set-Clipboard:Remote'] = $env:SSH_CLIENT -or $env:SSH_TTY to their $PROFILE.
2. Some terminal multiplexers like screen and tmux may require wrapping OSC52 into a different escape, as can be seen in the vim plugin implementation. Should we detect and handle those cases? tmux can be forced to work with default escape by setting set -s set-clipboard on. I would say keep it simple for now, then maybe add -RemoteMethod = auto | osc52 | tmux | screen in separate issue if required.

Proposed technical implementation details (optional)

See example for the escape sequence format.

[jhoneill]

I was just about to say something similar to @237dmitry

This is a good idea, but there doesn’t appear to be any way for the remote session to know what OSC commands are supported (see also https://github.com/PowerShell/PowerShell/issues/18098#issuecomment-1249224249 ) . It is a useful thing to add but may cause wrong expectations if it is the default

@237dmitry the two formats

dGVzdAo= <— Contains “test” with a trailing Line feed
dGVzdA== <— Contains “test” only.

I’m guessing the latter is preferred but the former is mostly harmless.

[msftbot[bot]]

🎉This issue was addressed in #18222, which has now been successfully released as v7.4.0-preview.4.🎉

Handy links:

• Release Notes