Does VS Code Remote SSH Share Your Local Clipboard?

VS Code's Remote-SSH extension runs the VS Code server process on a remote machine and the UI on the local machine. The editor looks local; the files, terminals, and language servers are remote. This split is convenient for developing on a Linux box from a Windows laptop, but it creates a clipboard boundary that is not always obvious. Text copied in the remote terminal may or may not end up on the local clipboard. A file copied in the remote Explorer may or may not be pasteable into a local application. The behaviour depends on which VS Code component did the copy, which clipboard it wrote to, and whether the Remote-SSH clipboard forwarder is enabled. This guide covers what crosses, what does not, and how to verify.

For neighbouring topics, see binary files on the clipboard: just don't, copying commit messages with the right wrap, and best clipboard habits for developers in 2026. For the WSL side, see WSL and Windows clipboard: what crosses the boundary.

How Remote-SSH splits the work

When a developer connects VS Code to a remote host over SSH, two processes are involved:

• The VS Code client runs on the local machine (Windows, in this guide's scope). It renders the UI, handles keyboard and mouse input, and writes to the local clipboard.
• The VS Code server runs on the remote machine (Linux, typically). It reads and writes files, runs the integrated terminal, hosts language servers, and executes tasks.

The two processes communicate over an SSH channel. The channel carries editor operations, file contents, terminal output, and — importantly — clipboard forwarding.

The clipboard forwarding is bidirectional in default configuration:

• Local-to-remote: when the user copies in a local application (a browser, a local terminal) and pastes in the remote VS Code terminal or editor, the local clipboard text is forwarded to the remote server, which writes it to the remote clipboard and then pastes.
• Remote-to-local: when the user copies in the remote terminal or editor, the remote server sends the text back over the SSH channel, and the VS Code client writes it to the local clipboard.

This forwarding is what makes Remote-SSH feel like local development. Without it, every cross-boundary paste would require a manual sync step. With it, the developer can copy a URL from a local browser and paste it into a remote curl command without thinking.

What crosses, what does not

The forwarding handles plain text by default. Other clipboard formats behave differently:

The image limitation is the most commonly encountered surprise. A developer copies a screenshot locally with Win+Shift+S, switches to the remote VS Code terminal, and tries to paste into a Markdown file. The paste does nothing, because the bitmap on the local clipboard was not forwarded. The workaround is to save the screenshot to a file on the local machine, transfer the file to the remote machine (SCP, rsync, or a sync folder), and reference it by path in the Markdown.

The file limitation is similar. A developer copies a file in the local Explorer and tries to paste into the remote VS Code Explorer. The paste does nothing, because file drop lists are not forwarded. The workaround is to use SCP, rsync, or the scp command from a local terminal.

Verifying the clipboard forwarder

The Remote-SSH extension has a setting that controls clipboard forwarding. The setting is remote.SSH.useExecServer in some versions and remote.SSH.clipboardSupport in others; the exact name has changed across releases. The current state can be checked in VS Code's Settings UI by searching for "remote SSH clipboard".

When clipboard forwarding is working, a copy in the remote terminal writes to both the remote clipboard and the local clipboard. The local clipboard write is what the developer observes: pasting into a local application works.

When clipboard forwarding is broken, a copy in the remote terminal writes only to the remote clipboard. Pasting into a local application pastes whatever was previously on the local clipboard, not the new remote copy. The developer usually notices this as "my copy isn't working" — the local paste gives stale content.

The most reliable verification: copy a unique string in the remote terminal (for example, echo "test-$(date +%s)"), then paste in a local Notepad. If the timestamp appears, forwarding works. If the previous local clipboard contents appear, forwarding is broken.

Common failure modes

Remote clipboard utilities missing

The VS Code server uses the remote machine's clipboard utilities to write to the remote clipboard. On Linux, this is usually xclip or xsel. If neither is installed, the server cannot write to the remote clipboard, and remote-to-local forwarding fails.

The fix: install xclip (or xsel) on the remote machine.

sudo apt install xclip        # Debian, Ubuntu
sudo dnf install xclip        # Fedora, RHEL

VS Code's Remote-SSH extension usually detects the missing utility and warns in the output panel, but the warning is easy to miss.

DISPLAY not set

The remote clipboard utilities expect an X display. On a headless remote machine (a VPS, a container), DISPLAY is often not set, and xclip fails silently. The VS Code server sets DISPLAY for its own subprocesses in most configurations, but if the developer has overridden the shell environment, DISPLAY may be missing.

The fix: check echo $DISPLAY in the remote terminal. If it is empty, the VS Code server's display forwarding is not active. Restart the VS Code server (Remote-SSH: Kill VS Code Server on Host from the command palette, then reconnect).

X11 forwarding conflicts

If the developer connected to the remote machine with ssh -X (X11 forwarding), the local X server may intercept clipboard writes. This produces confusing behaviour: copies in the remote terminal may go to the local X clipboard instead of the VS Code forwarding path. The fix is to connect without -X; VS Code's Remote-SSH does its own clipboard forwarding and does not need X11.

Remote clipboard daemon crashed

On Linux desktop remotes (a remote machine with a full desktop environment), the clipboard daemon (clipit, parcellite, copyq) may crash or be killed. The remote clipboard stops working, and VS Code's forwarding has nothing to forward. The fix is to restart the daemon or to disable it and let VS Code handle the clipboard directly.

The WSL parallel

The same boundary exists between Windows and WSL, and the same forwarding pattern applies. WSL's clip.exe and powershell.exe Get-Clipboard are the bridges. The pattern:

• From WSL to Windows: echo "text" | clip.exe writes to the Windows clipboard.
• From Windows to WSL: powershell.exe Get-Clipboard reads the Windows clipboard into WSL stdout.

The WSL boundary is more transparent than the Remote-SSH boundary because both sides run on the same machine, but the underlying mechanism is the same: text crosses, files and images do not.

For more on the WSL side, see WSL and Windows clipboard: what crosses the boundary and how to copy a file path that works in the terminal.

Files: use rsync, not the clipboard

For files that need to move between the local and remote machines, the clipboard is the wrong tool. The right tools are:

• scp local_file user@host:/remote/path/ — single file, one-shot.
• rsync -avz local_dir/ user@host:/remote/dir/ — directory, incremental, resumable.
• VS Code's Remote-SSH Explorer drag-drop — for files under a few MB, the Explorer supports drag-drop from the local Explorer to the remote Explorer. This uses SCP under the hood and is the most convenient for ad-hoc transfers.
• A synced folder — for files that change frequently, a folder synced through Syncthing, rsync on a cron, or a network filesystem mount.

The clipboard's role in file transfer should be limited to copying paths, not copying file contents. A path copied locally can be pasted into a remote terminal as an argument to scp. The actual file transfer is done by scp, not by the clipboard.

For more on the broader pattern, see binary files on the clipboard: just don't and copying files vs copying file contents.

Security: what stays on the remote

The clipboard forwarding means that anything copied in the remote terminal is, briefly, on the local clipboard. This is usually fine, but it has security implications:

• Remote secrets reach the local machine. A secret copied in the remote terminal (a database password, an API key) is forwarded to the local clipboard and ends up in local Win+V history if Win+V is enabled. The secret is now on two machines.
• Local clipboard managers capture remote copies. If a local clipboard manager (Ditto, CopyQ) is running, it captures everything that arrives on the local clipboard, including remote copies. Remote secrets are now in the local manager's database.
• Cloud sync, if enabled, sends remote copies to the cloud. If local cloud sync is on, remote secrets are synced to the cloud along with local ones.

The mitigation: disable cloud sync on the local machine, and configure the local clipboard manager to ignore the VS Code client process if possible. The deeper mitigation is to not copy secrets in the remote terminal at all; use a remote password manager or environment variables instead. See the .env file should never touch history for the broader habit.

A short checklist

• Plain text crosses the Remote-SSH boundary by default. Files, images, and rich text do not.
• If remote-to-local copy stops working, check that xclip or xsel is installed on the remote machine and that DISPLAY is set.
• For file transfer, use scp, rsync, or VS Code's Explorer drag-drop. Do not use the clipboard.
• Be aware that remote copies reach the local clipboard and any local clipboard manager. Disable cloud sync on the local machine.
• Verify forwarding with a unique string: echo "test-$(date +%s)" in the remote terminal, then paste in a local Notepad.

Related reading

• Copying Commit Messages With the Right Wrap
• Gists vs Clipboard for Sharing Throwaway Code
• Best Clipboard Habits for Developers in 2026
• Clipboard Tools on Multi-Monitor Windows Setups

Sources

• VS Code — Remote Development documentation — official overview of VS Code's Remote-SSH, Remote-Containers, and Remote-WSL extensions, including the client/server split
• VS Code — Remote SSH tips and tricks — official troubleshooting guide for Remote-SSH, covering clipboard forwarding failures and missing remote utilities
• Microsoft Learn — Windows Subsystem for Linux documentation — official WSL documentation, including the clip.exe and powershell.exe Get-Clipboard bridges between WSL and Windows
• OpenSSH — ssh command manual — official ssh man page, including the -X (X11 forwarding) flag that can interfere with VS Code's clipboard forwarding
• Microsoft Learn — Clipboard formats (Win32) — official reference for the clipboard formats that the local Windows side of the forwarding path can carry

Copy. Stack. Drop.

Transform your clipboard into an interactive edge shelf. Stack, pin, and drag assets into any app with zero friction.

Download for Windows Get from Microsoft Store

How to Install Guide · First 10 Minutes Guide · Drag & Drop Guide · Edge-Drop vs Win+V · Support