I keep a small text file on my desktop called sandbox-trace.md. Every time I open a fresh Windows Sandbox (the built-in Hyper-V virtual machine that lets you run a throwaway copy of Windows in a window on your desktop and throw it away when you close it), I spend the first minute writing down what is already running before I touch anything inside the window. After two years of doing this, the trace file is the most honest threat-model document I own. The defaults are not what most people think they are, and the only way I learned that was by forcing myself to look at the empty room before anything happened in it.
That habit is the whole reason this article exists. Most Sandbox guides skip the audit step and jump straight to “open it and run your suspicious installer.” That advice assumes the room you are walking into is empty. It is not. Two specific features ship enabled, and a third one is enabled by default in a way that surprises almost everyone the first time they see it.
What the trace file actually shows
The first line of every trace is the same: the network icon in the system tray is already lit up. There is no prompt. There is no first-run wizard. The Sandbox comes out of the box with a working internet connection through the Hyper-V virtual switch that lives on your host. The second line is the clipboard test: open Notepad inside the Sandbox, press Ctrl+V, and the host clipboard contents land inside the throwaway VM as if nothing happened. The third line is the one I missed for the longest time. The Sandbox auto-shares your host user folder as a read-only mapped drive. I never asked for that, and there is no obvious toggle in the Settings app to turn it off without editing the .wsb configuration file by hand.
None of those three behaviors break the isolation in a strict technical sense. Sandbox still runs a separate kernel inside hardware virtualization. Your host filesystem is mapped read-only, which means anything inside the Sandbox can read but cannot write to your files. The damage model is not “the Sandbox writes to my hard drive.” The damage model is “the Sandbox can call home, read my clipboard, and walk through my Documents folder without asking.” Those are different problems with different fixes, and the trace file is how I keep them straight.
Why the friendly defaults are the wrong defaults for testing
Microsoft picks these defaults because the median Sandbox user is a developer testing a portable app they mostly trust, or a curious person who wants to click on something sketchy without breaking their real machine. For that user, network access and clipboard sharing are features, not bugs. A network-enabled sandbox can install dependencies. A clipboard-enabled sandbox lets you paste a license key without retyping it. Microsoft optimized for the common case, and the common case is not testing malware.
The mismatch is not subtle once you see it. If you open a fresh Sandbox to look at an executable a stranger emailed you, and the executable’s first action is to phone home, you have given it exactly the thing you were trying to prevent: outbound network from a system that was supposed to be cut off. If your clipboard happened to hold a password manager export or a half-written confidential document when you opened the Sandbox, you just handed both over. If the executable wants to walk through your Documents folder looking for browser cookies or SSH keys, the auto-mapped read-only folder is a free directory listing. None of those scenarios require a sophisticated attacker. They require only that you trust the defaults instead of auditing them.
I am not arguing Microsoft is wrong. I am arguing the defaults are tuned for one use case and shipped for all of them. The trace file is how I retune them for my own use case without rewriting the Sandbox itself.
The configuration file is the only honest fix
Sandbox ships with a configuration language that most users never see. A .wsb file is a plain text XML document you can write in Notepad, save with the .wsb extension, and double-click to launch a Sandbox with custom rules. The flags I lean on for the hardened profile fall into a small checklist I keep in the trace file:
- DisableNetworking. Kills the virtual switch and stops every outbound connection from inside the Sandbox.
- ClipboardRedirection. Stop the host clipboard from being readable inside the Sandbox, and stop the Sandbox clipboard from being pasteable on the host.
- MappedFolders. Explicit list of host folders the Sandbox can see. Empty list means no host filesystem at all.
- MemoryInMB. Caps how much host RAM the Sandbox can grab, which matters if you are running it on a laptop with 16 GB and want to keep headroom for the host.
- vGPU. Optional virtual GPU passthrough. I leave this on Enable because the few cases where I want it off are rare enough that I just close the Sandbox.
The actual config file looks like this and lives on my desktop pinned to the taskbar:
<Configuration>
<Networking>Disable</Networking>
<ClipboardRedirection>Disable</ClipboardRedirection>
<MappedFolders></MappedFolders>
<MemoryInMB>4096</MemoryInMB>
</Configuration>
Double-click that file and you get a hardened Sandbox. Double-click the regular Sandbox shortcut and you get the friendly default. The two configurations behave so differently that I treat them as different tools.
What you lose by going hardened, and what you keep
Disabling network and clipboard in a Sandbox is not free. The first time I tried it, I attempted to download a tool inside the Sandbox and nothing happened. The browser loaded, the page timed out, and I had to download the file on the host and copy it into the Sandbox through a USB drive. That is annoying when you are in a hurry. It is also the entire point. If the executable you are testing secretly tries to dial out, you will see the failure in plain text inside the Sandbox, which is the information you wanted in the first place.
The other cost is habit. Windows does not let you flip the global Sandbox defaults through the Settings app, so every hardened session requires opening the .wsb file by hand. I solved that by pinning the file to the taskbar and never using the regular Sandbox shortcut. The unconfigured Sandbox becomes the one I avoid.
Disabling these features does not make the Sandbox invisible. A determined piece of malware can still try to fingerprint the host through shared virtual hardware or by measuring how long certain operations take. The point is not to make Sandbox perfect. The point is to stop handing sketchy software free network, free clipboard, and a free directory listing of your Documents folder just because you forgot to check what was already on.
Trade-offs
A hardened Sandbox is a specialty tool. If you only ever use Sandbox for portable apps you already trust, the friendly defaults are fine and the extra friction is not worth it. If your workflow includes opening executables from strangers, downloading files from links you do not fully trust, or browsing websites you would rather not associate with your real IP address, the hardened profile pays for itself the first time it catches a connection attempt you did not expect.
There is also a usability trade-off that the marketing copy never mentions. A Sandbox without clipboard redirection means you cannot paste a download URL from your email into the Sandbox browser. The workaround is to download the file outside the Sandbox and pass it in through a USB drive or a shared folder you explicitly opt into. For most people, that extra step is the entire point. For some people, it is a deal-breaker. Decide based on what you are actually testing.
The honest verdict: if Sandbox is your first line of defense for unknown software, harden the defaults. If Sandbox is just a convenience layer for testing apps you mostly trust, leave the defaults alone and accept the friendly version.
Bottom line
Open Notepad, paste the four-line config above, save it as safe-sandbox.wsb on your desktop, and pin it to the taskbar. The next time you need to test an executable you do not trust, double-click that file instead of opening Sandbox through the Start menu. You will give up a little convenience. You will gain the version of Windows Sandbox you actually thought you had.