sandbox-mcp

Give your AI agent a brand-new Windows PC. Then throw it away.

Not your desktop. Not a container pretending to be Windows. A real, disposable Windows 11 machine: boot it, deploy your app, drive the controls, catch the crash, keep the evidence, delete the PC. Run it directly with sbx; the optional MCP adapter exposes discoverable tools and inline images for clients that want them. Both interfaces use the same engine. The measured GUI samples take roughly 40-50 seconds end to end. See the website.

Real app, real guest: Haptics Everywhere's self-contained WPF/WinForms desktop app in a fresh, network-off Sandbox. UIA selects the Inspector, the guest switches light to dark, the app relaunches and exits, then the guest is destroyed. 10-second, 183 KB edited footage: light Inspector slowed for readability, repeated dark frames trimmed. Boot/teardown title cards summarize actual logs, not filmed boot/shutdown. No guest runtime installation or haptic-hardware claim. Fresh dark lab screenshot · Earlier light-theme inspector.

🤖 Let your agent set it up

Give this to your bot. It checks the PC, verifies the download and asks before admin changes or a restart. The CLI works on its own; configure MCP only if your agent needs that interface:

Set up the sandbox-mcp CLI by following:
https://raw.githubusercontent.com/shanselman/sandbox-mcp/main/docs/agent-setup.md
Install the latest verified release. The CLI must work without MCP; configure the optional MCP adapter only if my agent needs it. Ask before admin changes or a restart.

Download v1.2.0: portable CLI + optional MCP server, bundled Node.js, guest agent and setup instructions. No Node/npm installation needed.

“Works on my machine.” Caught in 30 seconds.

The dev box had Visual C++ installed. The fresh, network-off customer PC did not:

FAIL  NativeProof.exe on a fresh Windows Sandbox (29.8s)
  why      exited with code -1073741515; Missing dependency: VC++ redistributable.

Opt in to the verified runtime install, then repeat on another fresh guest:

PASS  NativeProof.exe on a fresh Windows Sandbox (30.9s)
  baseline PROVISIONED (not a clean-machine pass): VC++ redistributable  x64
  process  exited with code 0

Those are actual measured results, not illustrative output. The installer was Microsoft-signed 14.51.36247.0, downloaded and verified on the host. Guest networking stayed off. sbx deps app.exe diagnoses; sbx run app.exe --provision auto installs only when explicitly requested.

What your agent gets

Same clean-machine loop, different frameworks:

WinUI 3, packaged	WPF, self-contained	Native Win32, packaged

These are real offline-guest screenshots, not host mockups. WinUI/WPF were refreshed against the final integrated source; the full matrix covers seven configurations. Exact builds, timings, startup defects found and remaining coverage gaps are in the compatibility evidence.

Download/setup · Agent setup guide · Measured compatibility and honest limits · CLI and MCP interfaces

This 138 KB animation comes from a new 74-frame guest recording: UIA changes the text, invokes buttons and increments the counter. The guest was stopped afterward; the HTML viewer, MP4 and frames remained on the host. No synthetic screenshots. This small fixture proves the automation path; the rich app above shows the real-app use case.

Why

A Windows Sandbox showcase, not a framework gate. WinUI 3 is welcome, but the entry point is a Windows executable or package, not a particular UI framework. Bring an app that can run in Sandbox and its prerequisites: Win32, WinForms, WPF, WinUI, console, PyInstaller or Electron builds use the same clean-machine workflow. Installers and untrusted files have their own audit/detonation workflows. This is not a promise that every Windows app or hardware-dependent workload works in Sandbox. See the measured compatibility matrix and small source samples in this matching checkout for the configurations actually exercised.

winapp CLI's Sandbox execution also supports packaged and unpackaged apps: its --on sandbox offers a warm, identity-aware developer loop, runtime preparation and WinUI diagnostics. sandbox-mcp emphasizes fresh-by-default clean-machine reports, network-off shared-folder mailbox transport, installer/uninstaller diffs and detonation. The tools have overlapping app support but different defaults and goals; sandbox-mcp never implicitly installs app prerequisites. Inbox Framework/CBS components can exist, but are not proof that an app's requested runtime is available.

"It works on my machine" is usually true: your machine has every runtime, SDK, redistributable, font, registry key and PATH entry you ever installed. Your users' machines don't. Windows Sandbox is a pristine Windows that boots in seconds and is deleted when it closes, which makes it the perfect "brand-new customer PC". Its supported wsb CLI provides automation; sandbox-mcp adds orchestrated app deployment, UI Automation, clean-machine checks and durable test evidence around it.

If you need many machines, persistence, or Linux, use a VM or a cloud box. If you want to know "does my Windows app install, launch and work on a clean PC, and what does it look like?" as quickly and cheaply as possible, this is it.

What you can do

sbx deps <app.exe|folder> (MCP: sandbox_deps) inspects dependencies on the host without running or installing anything: PE architecture/imports, app-local VC++ DLLs, .NET runtime configs, .NET Framework configs, package dependencies and script interpreters. sbx run includes this diagnosis in its report and names likely missing runtimes after a failed launch. This is a conservative static scan, not proof that every dynamic dependency is present. Optional guest components such as WebView2 must be checked in the actual guest.

The default never installs dependencies. To explicitly opt in, use sbx run <app> --provision auto (sandbox_run parameter provision: "auto"), or specify a comma-separated list such as --provision desktop:10.0:x64,vcredist:x64. Supported components: dotnet:<version>:<arch>, desktop:<version>:<arch>, aspnetcore:<version>:<arch>, vcredist:<arch> and windows-app-runtime:<major.minor>:<arch>. Architecture is x86, x64 or arm64 (explicit lists default to x64). sbx provision <host app path> --provision <auto|list> / sandbox_provision does the same in an already-started sandbox; it never starts or adopts a guest. Un