Windows Sandbox: A Safer Disposable Environment for App Testing

Windows Sandbox solves a wonderfully ordinary problem: sometimes you want to open an installer, test a utility, or reproduce a setup without leaving changes scattered across your main Windows installation. It launches a clean, lightweight Windows environment, lets you work inside it, and discards the session when you close it.

That convenience can also encourage a dangerous shortcut in thinking. A disposable desktop is not the same as perfect containment. Windows Sandbox is built on hardware virtualization, but its default configuration still enables networking, clipboard sharing, audio input, and virtualized graphics. Those connections are useful for routine app testing; they are also trust paths that matter when the file is genuinely suspicious.

This guide sets up Windows Sandbox for practical testing, then tightens those defaults with a reusable .wsb profile. The goal is not to build a malware-analysis laboratory. It is to reduce the blast radius of normal software evaluation while knowing when to stop and use a dedicated, isolated environment instead.

What Windows Sandbox is good at

Windows Sandbox is a lightweight virtualized Windows desktop generated from components already present on the host. The Microsoft overview describes it as disposable, pristine, and isolated through the Microsoft hypervisor. Applications installed inside it are separate from the host installation, and closing the Sandbox deletes its software, files, and state. A new launch starts with a fresh environment.

That makes it a strong fit for tasks such as:

• checking the installation flow of a legitimate utility;
• opening a document from a known sender when its behavior is uncertain;
• reproducing an application problem on a clean Windows environment;
• testing a script that should not change the host;
• exploring a tool without committing it to the main system.

The word disposable needs one nuance. Microsoft notes that, beginning with Windows 11 version 22H2, data survives restarts initiated inside the running Sandbox so installers can complete a reboot. The state is still discarded when the Sandbox application is closed. If you need a persistent laboratory across separate sessions, snapshots, multiple network segments, or a custom operating-system image, use a full virtual machine instead.

Windows Sandbox also serves a different purpose from Windows Subsystem for Linux. WSL is a maintained environment for Linux tools and workflows. Sandbox is a temporary Windows environment intended to be thrown away. Choosing between them is about lifecycle, not which virtualization feature sounds more advanced.

Check support before enabling the feature

The current Microsoft installation requirements list supported Pro, Enterprise, and Education editions of Windows 10 and Windows 11; Windows Home is not supported. The device also needs AMD64 hardware, or Arm64 on Windows 11 version 22H2 or later, with virtualization enabled in firmware. Microsoft lists 4 GB of RAM, 1 GB of free disk space, and two CPU cores as minimums, while recommending 8 GB of RAM, an SSD, and four cores with simultaneous multithreading for a better experience.

Before making a change, confirm the Windows edition under Settings → System → About, then check Task Manager’s CPU performance page for virtualization status. If virtualization is disabled, consult the device or motherboard documentation before changing firmware settings. Do not guess at unrelated BIOS options.

To enable the feature through the graphical interface:

1. Search for Turn Windows features on or off.
2. Select Windows Sandbox.
3. Choose OK and restart if Windows requests it.
4. Launch Windows Sandbox from Start.

Microsoft also documents this elevated PowerShell command:

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

If the feature is unavailable, stop there and recheck the edition, hardware architecture, and virtualization support. Do not work around the requirement with unofficial packages or registry edits. The rollback is straightforward: return to Windows Features, clear Windows Sandbox, accept the change, and restart if prompted.

The default Sandbox still shares useful host capabilities

A default launch prioritizes convenience. According to Microsoft’s Windows Sandbox configuration reference, networking and clipboard redirection are enabled. Audio input is enabled, virtualized GPU support is enabled on non-Arm64 devices, and Protected Client mode is disabled. Video input and printer redirection are disabled.

Those defaults explain why copying an installer into the window and downloading a dependency feels effortless. They also explain why the default profile should not be described as air-gapped.

| Boundary | Default | Why it matters |
|—|—|—|
| Networking | Enabled | Software can reach the internet and may reach services on the local network. |
| Clipboard | Enabled | Text and files can move between host and Sandbox. |
| Mapped folders | None until configured | A writable mapping can preserve changes on the host after the Sandbox closes. |
| vGPU | Enabled on supported devices | Improves graphics performance but adds a shared device path. |
| Protected Client | Disabled | Additional AppContainer isolation is not active by default. |

Mapped folders deserve special care. A read-only mapping is useful for presenting an input file to the Sandbox without allowing the session to overwrite that folder. A writable mapping deliberately crosses the disposable boundary: any change made there persists on the host. Never map a home directory, cloud-synced folder, password store, SSH directory, or repository containing credentials into a test session.

The clipboard is similarly easy to underestimate. Copying a password on the host while clipboard sharing is active can expose it to software in the Sandbox. Clear sensitive clipboard content before launch or disable redirection in the profile.

Build a safer profile for unknown files

Windows Sandbox reads XML configuration files with the .wsb extension. The following profile favors isolation over convenience. It disables networking, virtualized GPU, clipboard sharing, and device redirection; enables Protected Client; and exposes only one dedicated input folder as read-only.

First, create C:\SandboxInput on the host and place only the file you intend to inspect inside it. Then save this configuration as SaferTest.wsb:

<Configuration>
  <VGpu>Disable</VGpu>
  <Networking>Disable</Networking>
  <MappedFolders>
    <MappedFolder>
      <HostFolder>C:\SandboxInput</HostFolder>
      <SandboxFolder>C:\Input</SandboxFolder>
      <ReadOnly>true</ReadOnly>
    </MappedFolder>
  </MappedFolders>
  <AudioInput>Disable</AudioInput>
  <VideoInput>Disable</VideoInput>
  <ProtectedClient>Enable</ProtectedClient>
  <PrinterRedirection>Disable</PrinterRedirection>
  <ClipboardRedirection>Disable</ClipboardRedirection>
  <MemoryInMB>4096</MemoryInMB>
</Configuration>

This follows the pattern in Microsoft’s official sample configuration, which disables networking and vGPU and maps the download source read-only. Double-click the .wsb file to launch that profile.

There is a deliberate usability cost. With networking disabled, installers cannot fetch components. With clipboard redirection disabled, copy and paste between host and guest is restricted. Protected Client can further limit some redirection behavior. Those inconveniences are evidence that the boundaries are working, not configuration bugs to remove automatically.

Use a repeatable test and verify the cleanup

Start by recording what you are testing and where it came from. If the publisher provides a cryptographic hash or digital signature, verify it before launch. The Sandbox should complement source verification, not replace it.

Then follow a small runbook:

1. Close password managers, administrative consoles, and sensitive documents on the host.
2. Clear the host clipboard and place only the test item in C:\SandboxInput.
3. Launch SaferTest.wsb and confirm that C:\Input is present.
4. Confirm that web access is unavailable and host-to-Sandbox paste is blocked.
5. Copy the item from the read-only mapping to the Sandbox desktop before running it.
6. Observe installation paths, requested privileges, services, startup entries, and network assumptions.
7. Export only notes or artifacts you have deliberately reviewed; do not make the input mapping writable for convenience.
8. Close Windows Sandbox and accept the deletion prompt.

For a harmless acceptance test, create a marker file on the Sandbox desktop, close the application, and launch the same profile again. The marker should be gone. The original host file in C:\SandboxInput should remain unchanged, and the Sandbox should still lack network access. Those checks prove the profile you launched behaves as expected; they do not certify the safety of an unknown executable.

Remember that environment changes inside the session disappear too. If a test depends on PATH or another variable, configure it inside the Sandbox rather than altering the host. The distinction is clearer after reviewing how Windows system environment variables are scoped and managed.

Know when to choose a full virtual machine

Windows Sandbox is optimized for quick, disposable sessions. A full VM is the better tool when you need persistent snapshots, multiple reboots across separate sessions, custom network capture, more than one guest, a different Windows build, or repeatable forensic instrumentation. A separate physical analysis machine is safer still when the sample is believed to target virtualization or when the host contains high-value credentials.

Sandbox is also a poor substitute for ordinary endpoint hygiene. Keep Microsoft Defender and Windows security updates active. Verify publishers and signatures. Use backups. Avoid granting administrator rights simply because the test environment is temporary. If software looks clean in one short run, that does not prove it lacks delayed behavior or environment-aware logic.

The strongest use case is therefore modest and valuable: evaluating legitimate or uncertain software with fewer lasting changes to the host. That is a much more defensible promise than “run anything safely.”

Conclusion

Windows Sandbox turns a clean Windows desktop into an on-demand, disposable workspace. For routine app testing, that is faster and simpler than maintaining a full virtual machine. Its value comes from easy reset and hypervisor-based isolation, not from immunity to every threat.

Use the default profile for low-risk compatibility checks when its integrations are helpful. Use a restricted .wsb profile when the file is less trusted: disable networking and clipboard redirection, map only a dedicated input folder as read-only, and enable Protected Client. For suspected malware, move to a purpose-built analysis environment. The professional habit is not trusting the word sandbox; it is defining every path that crosses its boundary.