sbx launches your Windows app in a throwaway PC and keeps the screenshots after it crashes

Every developer has said it: “works on my machine.” The machine in question has a dozen runtimes, SDKs and half-installed fixes the customer’s laptop will never see.

The sandbox-mcp README opens with “A real, disposable Windows 11 machine.” Its sbx command starts one through Windows Sandbox, runs your program in it, and leaves the evidence on the host. The README says “every run keeps screenshots, copied-out files, a markdown report and an audit log on the host after the sandbox is gone.” A passing run leaves report.md, report.json, screenshots and audit.jsonl.

Windows Sandbox is Microsoft’s own feature, and the doc spells out the trick this tool builds on: “closing it deletes all software, files, and state. Each launch provides a fresh instance. Host-installed software isn’t available in the sandbox.” The tool adds the plumbing that turns a throwaway window into a bug report.

The README’s failed-run example shows why that matters. A test program called NativeProof.exe comes back with “FAIL NativeProof.exe on a fresh Windows Sandbox (29.8s)” and the reason “exited with code -1073741515; Missing dependency: VC++ redistributable.” That’s the classic developer-machine trap, caught in 30 seconds without touching your own install.

Then it gets careful. The default never installs anything: “The default never installs dependencies.” Run sbx run app.exe --provision auto and it installs the missing runtime, but the second report reads “PASS NativeProof.exe on a fresh Windows Sandbox (30.9s)” with the baseline marked “PROVISIONED (not a clean-machine pass).” The fix worked, and the report refuses to pretend your customer’s PC already had it. A separate sbx deps app.exe command does a “conservative static scan, not proof that every dynamic dependency is present.”

Networking is where I’d read the fine print. Microsoft’s doc says “Windows Sandbox enables network connection by default.” For sbx run, the README’s network table also marks on as the default. --network off boots the guest with “no network adapter.” There’s a separate sbx detonate command for untrusted files that runs with no adapter by default, and it reports findings as “heuristics, not a verdict.”

The README is just as blunt about limits. “This is not a promise that every Windows app or hardware-dependent workload works in Sandbox.” “Exit code 0 means “it was observed”, not “it’s safe”.” And “This is a quick first look on your own PC, not a malware lab.” It also warns that the out folder is writable from inside the guest, so treat anything it returns as untrusted.

You need the right Windows. The README says “Windows Sandbox is only available on Windows Pro, Enterprise or Education; Windows Home and Windows Server cannot run it,” and lists Windows 11 24H2 (build 26100) or later. Microsoft’s table agrees on the editions. The tool installs from a portable ZIP that bundles sbx, an MCP server, a private Node.js runtime and the guest agent, so there’s no repo to clone.

The MCP server is the optional part. The README says “The sbx CLI is fully usable without an MCP server,” and calls MCP “an optional adapter for agents that benefit from discoverable tool schemas.”

A built-in Windows feature plus one command and a report is the kind of small tool that gets passed around a team. Expect the dull, useful checks to spread first: does the installer run on a PC with nothing on it, and what does the screen look like when it doesn’t?

The README says outright that it’s no malware lab, and the 30-second failure was a missing redistributable. Sometimes the villain really is that boring.