How to Set Up and Use Windows Sandbox

Windows Sandbox provides a lightweight, temporary, isolated desktop environment for running untrusted software safely — every session starts clean and is discarded entirely on close, with none of the setup overhead of maintaining a dedicated virtual machine image.

Step 1: confirm system requirements

Windows 10/11 Pro, Enterprise, or Education edition
(not available on Home edition)
Virtualization enabled in BIOS/UEFI
At least 4GB RAM (more recommended)

Step 2: enable the Windows Sandbox feature

Control Panel → Programs → Turn Windows features on or off →
  check "Windows Sandbox" → OK → restart when prompted

Or via PowerShell (as Administrator):

Enable-WindowsOptionalFeature -FeatureName "Containers-DisposableClientVM" -All -Online

Step 3: launch Windows Sandbox

Start menu → Windows Sandbox

A fresh, clean Windows desktop opens in its own window within moments — no separate ISO, no VM setup wizard, no persistent disk image to manage between sessions.

Step 4: run untrusted software inside it

Copy an installer or executable into the Sandbox window (drag-and-drop from the host works directly) and run it there instead of on your actual machine — anything it does is contained entirely within the Sandbox environment.

Step 5: close the Sandbox when done

Simply closing the Sandbox window discards the entire environment — every file, every registry change, every installed application from that session disappears completely, with no cleanup required on your part.

Step 6: use a configuration file for a customized, repeatable Sandbox setup

<!-- mysandbox.wsb -->
<Configuration>
  <MappedFolders>
    <MappedFolder>
      <HostFolder>C:\SandboxShare</HostFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>
  </MappedFolders>
  <LogonCommand>
    <Command>explorer.exe C:\Users\WDAGUtilityAccount\Desktop</Command>
  </LogonCommand>
</Configuration>

Double-clicking a .wsb file launches a Sandbox session configured according to its settings — useful for a repeatable setup that automatically shares a specific folder or runs a specific startup command, rather than configuring the same thing manually every session.

Step 7: map a folder read-only for safely testing files without exposing your whole system

<MappedFolders>
  <MappedFolder>
    <HostFolder>C:\Downloads\untrusted</HostFolder>
    <ReadOnly>true</ReadOnly>
  </MappedFolder>
</MappedFolders>

A read-only mapped folder lets the Sandbox environment access specific files from the host without any risk of the Sandbox session writing back to or modifying anything on the host system.

A few more `.wsb` options worth knowing about

The configuration file supports several other settings beyond mapped folders and a logon command: <vGPU>Disable</vGPU> turns off virtualized GPU acceleration for a session that needs to avoid exposing any GPU-level attack surface, <Networking>Disable</Networking> cuts off the sandbox’s network access entirely for testing something that shouldn’t be allowed to phone home at all, <MemoryInMB> caps how much RAM the session is allowed to consume, and <AudioInput>/<VideoInput> control whether the sandbox can see the host’s microphone or camera. Each of these defaults to enabled except where noted, so a config file built for genuinely untrusted software is worth tightening deliberately rather than relying on the permissive defaults meant for general-purpose convenience.

Step 8: understand what Sandbox is (and isn’t) appropriate for

Windows Sandbox is well suited to quickly testing an installer, checking whether a suspicious file actually does anything malicious, or trying software you’re not sure you want to keep — all without any persistent trace on your real system. It’s not a substitute for a full, persistent VM when you need an environment that retains state between sessions, since by design nothing survives closing the window.

What’s actually happening architecturally when Sandbox starts

Windows Sandbox doesn’t boot a separate copy of Windows the way a conventional VM does. Instead, it uses what Microsoft calls a dynamic base image: since the sandbox is running the identical Windows build already installed on the host, nearly all of the OS image can simply be shared (via a Windows Container-derived mechanism) rather than duplicated onto disk, with only the small subset of files that must remain mutable actually copied into a compressed base package roughly 30MB in size. That combination — kernel-level isolation from Hyper-V, container-style resource sharing for everything that doesn’t need to be unique per session, and a base image that piggybacks on the host’s own OS files instead of shipping a redundant copy — is what lets a full, disposable Windows desktop start in seconds rather than the minutes a traditional VM typically needs to boot from a cold disk image.

When system requirements actually matter

Windows Sandbox first shipped as a built-in optional feature starting with Windows 10 version 1903, released in May 2019, and has remained Pro/Enterprise/Education-only since — Home edition users can’t enable it at all, a limitation tied to Windows Sandbox depending on the same Hyper-V virtualization platform that Home edition doesn’t otherwise expose. Virtualization support has to be enabled at the firmware level too (Intel VT-x/AMD-V, plus SLAT support on the CPU), which is occasionally the actual blocker on an older machine that otherwise meets every edition and RAM requirement — the feature will simply fail to enable, or fail to launch a session, until virtualization is turned on in BIOS/UEFI setup rather than through anything changeable from within Windows itself.

Why “no persistent state” is the entire point, not a limitation

Every other isolation approach — a dedicated VM, a container, a separate physical test machine — requires some ongoing maintenance to keep in a known-clean state. Windows Sandbox’s guarantee that literally nothing persists between sessions means every single launch starts from an identically clean baseline, with zero risk of a previous session’s changes accumulating and eventually undermining the isolation you’re relying on.

Related:

Sources: