Does Windows Sandbox Keep Clipboard History?

Windows Sandbox shares the host clipboard during a session, but Win+V history inside the sandbox is destroyed the moment the sandbox closes. The same applies to any clipboard manager running inside the sandbox. This is by design — the sandbox is disposable — but it confuses users who expect the sandbox's Win+V history to persist like the host's. This guide explains what crosses, what does not, and why a sandbox clip should never be treated as storage.

For the wider virtualisation picture, see VM guest clipboard integration broken for VMware, VirtualBox, and Hyper-V, third-party antivirus blocking clipboard access for security-suite interference, and the general Win+V not working on Windows 11: 9 fixes and Win+V Says 'Nothing Here'? How to Fix Clipboard History on Windows 11 references.

What Windows Sandbox is

Windows Sandbox is a disposable Windows environment built into Windows 10 Pro and Windows 11 Pro (and above). It launches from the Start menu as a lightweight, Hyper-V-based virtual machine. The base image is read-only; changes are written to a copy-on-write delta. When the sandbox closes, the delta is discarded and the next launch starts from the clean base image again.

The sandbox is designed for running untrusted executables, opening suspicious files, and testing configuration changes without risk to the host. It is not designed for persistent work, and it is not designed for clipboard storage.

Clipboard behaviour in-session

During a sandbox session, the host and sandbox share a clipboard over the redirected clipboard channel. This is the same mechanism Hyper-V Enhanced Session uses; the sandbox is, under the hood, a Hyper-V utility VM with redirection on by default.

• Host-to-sandbox: copy on the host, paste in the sandbox with Ctrl+V. Works for text, HTML, and bitmaps.
• Sandbox-to-host: copy in the sandbox, paste on the host with Ctrl+V. Works for text, HTML, and bitmaps.
• Files: file paste is more limited. Host-to-sandbox file paste works through the redirected clipboard; sandbox-to-host file paste is restricted and often silently dropped.

Win+V inside the sandbox works during the session, but only inside the sandbox. The host's Win+V history is not visible inside the sandbox, and the sandbox's Win+V history is not visible on the host.

Why history does not persist

Two separate mechanisms destroy sandbox clipboard state at close:

1. The sandbox's filesystem delta is discarded. Win+V history is stored on disk in the user profile. When the sandbox's delta is discarded, the history file goes with it. Nothing the user copied inside the sandbox during the session survives.
2. The sandbox's clipboard service is torn down. The Clipboard User Service that backs Win+V is stopped when the sandbox shuts down. Anything held only in memory is gone.

This is the same lifecycle that destroys browser history, downloaded files, and registry changes inside the sandbox. It is not a clipboard-specific limitation; it is the sandbox's core design.

What does not cross into or out of the sandbox

• Win+V history. Local to whichever side opened Win+V. Host history does not appear inside the sandbox; sandbox history does not appear on the host.
• Pinned items. Pinned Win+V entries stay on the side they were pinned on, and inside the sandbox they are destroyed at close.
• Cloud sync. Win+V cloud sync is PC-to-PC and does not extend into a sandbox session. Even if the host is signed into a Microsoft account with sync on, the sandbox is a separate Windows instance that does not inherit that account's sync state.
• Third-party clipboard managers on the host. Ditto, CopyQ, or Edge-Drop running on the host see only the host's clipboard. They do not see the sandbox's internal clipboard unless the sandbox pushes content to the host's clipboard via the redirected channel.
• Third-party clipboard managers in the sandbox. If a manager is installed and running inside the sandbox, its history is destroyed at close along with everything else.

Common confusion: "Win+V in the sandbox is empty"

A frequent report is that Win+V inside the sandbox shows an empty panel even after copying several items inside the sandbox. The cause is usually that Win+V history has not been enabled in the sandbox session. Each sandbox launch is a clean Windows instance; the "Turn on clipboard history" prompt must be answered each time. Until that is done, Win+V shows nothing and there is no history to destroy.

This is expected behaviour, not a bug. For the broader pattern of Win+V not saving items, see Win+V Says 'Nothing Here'? How to Fix Clipboard History on Windows 11.

Using a .wsb config file

A .wsb config file can mount a host folder inside the sandbox at launch. This is the closest thing to persistent state the sandbox offers. A typical .wsb file mounts a working folder as read-write so files saved into it survive the sandbox's shutdown.

<Configuration>
  <MappedFolders>
    <MappedFolder>
      <HostFolder>C:\Users\name\SandboxShare</HostFolder>
      <SandboxFolder>C:\Share</SandboxFolder>
      <ReadOnly>false</ReadOnly>
    </MappedFolder>
  </MappedFolders>
</Configuration>

This works for files. It does not work for clipboard history. Clipboard state is not a file the user can redirect; it lives in the user profile and in memory, both of which are destroyed at close.

The practical pattern for clipboard-style persistence across sandbox sessions: paste text into a file in the mounted folder, and copy it back out of the file in the next session. This is slower than Win+V but it is the only mechanism the sandbox supports.

Sandboxed apps that need to paste sensitive content

A common workflow is to open a suspicious document in the sandbox, copy a URL or string out of it, and paste that string into a host-side tool for analysis. The redirected clipboard supports this, but with caveats:

• Text crosses cleanly. Plain text is the most reliable format.
• Rich text is flattened. HTML and rich-text copies arrive as plain text on the host in many configurations.
• Images are larger and slower. Bitmaps cross, but a large screenshot can take noticeable time over the redirection channel.
• Files usually do not cross sandbox-to-host. If the goal is to extract a file from the sandbox, use the mounted shared folder, not the clipboard.

For sensitive content, the sandbox's ephemerality is a feature, not a bug. Anything pasted into the sandbox is destroyed at close, which is useful for inspecting untrusted content without leaving traces.

What Edge-Drop and other host managers see

Edge-Drop, the Windows clipboard shelf, runs on the host. It sees the host's clipboard. When the sandbox pushes text to the host clipboard via the redirected channel, Edge-Drop captures it like any other host clipboard event. When the sandbox closes, the host clipboard still holds the last item the sandbox pushed; Edge-Drop retains that item until it is cleared or replaced.

Edge-Drop does not run inside the sandbox and does not see the sandbox's internal clipboard. The sandbox is a separate Windows instance; installing Edge-Drop inside it would create a separate, sandbox-only instance whose state is destroyed at close. There is no benefit to doing this.

For more on the host-side manager's role, see Windows clipboard settings, line by line.

Troubleshooting checklist

• Confirm Win+V history is enabled inside the sandbox session (it must be re-enabled each launch).
• Confirm the host and sandbox are sharing a clipboard by copying plain text on the host and pasting into Notepad inside the sandbox.
• If the sandbox-to-host direction fails, copy plain text in the sandbox and paste into Notepad on the host. If text works but files do not, that is the expected restriction.
• If clipboard integration fails entirely, restart the sandbox. A hung redirected-clipboard channel is rare but resolves on relaunch.
• Do not expect sandbox Win+V history to survive close. It cannot, and no configuration makes it persist.

A short test sequence

When a user reports that the sandbox "lost all clipboard history", a 60-second test confirms whether the cause is the sandbox's design or an actual bug:

• Launch the sandbox and open Notepad inside it.
• Inside the sandbox, copy three distinct strings into the sandbox clipboard, one after another.
• Inside the sandbox, open Win+V. If the panel shows the three items, history is on; if it shows a "Turn on" prompt, history was off and that explains the earlier loss.
• Close the sandbox.
• Relaunch the sandbox and open Win+V inside the new session.
• The panel is empty, even though the same Microsoft account is signed in on the host. This is the expected outcome.

If the final step shows anything other than an empty panel, the cause is worth investigating. In practice it never does; the sandbox's delta is destroyed at close and Win+V starts fresh each launch.

What to avoid

• Treating the sandbox as a clipboard-storage location. State is destroyed at close by design.
• Trying to enable cloud sync inside the sandbox. Win+V cloud sync is PC-to-PC; a sandbox session is not a PC in that sense, and signing in with a Microsoft account inside the sandbox does not extend sync to it.
• Pinning items inside the sandbox and expecting them to survive. Pinned items are part of the user profile that is destroyed at close.
• Installing a clipboard manager inside the sandbox. It will be destroyed at close along with everything else.

Related reading

• Third-Party Antivirus Blocking Clipboard Access
• Corrupt Clipboard Cache After Insider Builds
• Win+V Not Working on Windows 11: 9 Fixes
• Best Free Clipboard Manager for Windows

Sources

• Microsoft Learn — Windows Sandbox overview — official description of the sandbox's disposable, copy-on-write model and the Hyper-V basis
• Microsoft Learn — Configure Windows Sandbox using a .wsb file — official documentation for the .wsb configuration format including MappedFolders
• Microsoft Support — Using the clipboard on Windows — official statement of the 25-item, 4 MB, text-HTML-bitmap limits and the optional cloud sync that does not extend into the sandbox
• Microsoft Learn — Hyper-V Enhanced Session Mode — documents the redirected clipboard mechanism that Windows Sandbox uses under the hood
• Microsoft Learn — Windows Sandbox system requirements — official prerequisites including virtualisation support in BIOS and Windows version

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