sandbox-mcpAn MCP server for Windows Sandbox
Give your AI agent a brand-new Windows PC. Then throw it away.
Your agent can write the app, but it can’t tell you if it runs on a PC that isn’t yours. With sandbox-mcp it can boot a clean Windows 11, run your build, click around and see what happened. Then the machine is deleted.
Try HelloSandbox on a clean PC. Type my name, click Greet and show me what happens.
sandbox_start{ "network": "off" }Clean Windows 11 ready
sandbox_copy_in{ "hostPath": "D:\\HelloSandbox" }Build copied in
sandbox_launch{ "path": "C:\\apps\\HelloSandbox\\HelloSandbox.exe" }Running as pid 4812
sandbox_ui_tree{ "pid": 4812 }Edit #NameBox = "" {setvalue} Button "Greet" #GreetButton {invoke}sandbox_ui_action{ "automationId": "NameBox", "action": "setvalue", "value": "Scott" }sandbox_ui_action{ "automationId": "GreetButton" }sandbox_screenshot{ "pid": 4812 }Hello SandboxScottHello, Scott!Greetsandbox_stop{ }Sandbox deleted, screenshots kept
It works on a clean PC. I typed Scott, clicked Greet and it said “Hello, Scott!”. The sandbox is gone.
App running on the sandbox desktop
Read the full demo transcript
sandbox_start: clean Windows 11 ready, network off.sandbox_copy_in: HelloSandbox build copied in.sandbox_launch: HelloSandbox is running.sandbox_ui_tree: found the NameBox and Greet button.sandbox_ui_action: entered Scott, then clicked Greet.sandbox_screenshot: shows “Hello, Scott!”.sandbox_stop: sandbox deleted; screenshots kept.
The tools are real. The desktop shown above is drawn.
What it does
Find out what happens on a PC that isn’t yours.
Your machine has every runtime and SDK you ever installed. Your users’ machines don’t.
Test your build sandbox_run
Starting isn’t proof. The included test sets a name, clicks Greet, waits for the exact label and compares a saved file. A missing runtime stays a failure.
> sbx run .\samples\HelloSandbox\bin --test .\samples\HelloSandbox\test.ps1
PASS HelloSandbox.exe on a fresh Windows Sandbox
test test.ps1 passed
> sbx run .\NativeProof.exe --network off
FAIL NativeProof.exe on a fresh Windows Sandbox (29.8s)
why exited with code -1073741515; Missing dependency: VC++ redistributable.See the actual UI assertions from test.ps1
$app = @{ ProcessId = $env:SBX_APP_PID }
Invoke-SbxUi @app -AutomationId NameBox -Action setvalue -Value 'Sandbox Tester' | Out-Null
Invoke-SbxUi @app -Name Greet | Out-Null
$label = (Wait-SbxUi @app -AutomationId Output -Name 'Hello, Sandbox Tester!' -TimeoutSec 5).name
$file = Join-Path $env:SBX_APP_DIR 'greeting.txt'
if ((Get-Content $file) -ne $label) { throw 'greeting.txt does not match the label' }
'PASS'Test your installer sandbox_install_test
It installs, uninstalls and shows you what the uninstaller forgot. A “silent” install that hangs comes back with a screenshot of the dialog.
> sbx install-test .\samples\LeakyApp\install.ps1
## Left behind after uninstall
Services: added service LeakyUpdater "Leaky App Updater", automatic: "C:\Program Files\LeakyApp\updater.exe"
Autoruns: added HKCU\Software\Microsoft\Windows\CurrentVersion\Run\LeakyUpdater
Files: C:\ProgramData\LeakyApp\ C:\Users\WDAGUtilityAccount\AppData\Roaming\LeakyApp\
C:\Windows\System32\Tasks\LeakyApp Daily Check
Registry: HKLM\SOFTWARE\LeakyAppOpen a file you don’t trust sandbox_detonate
Someone sent you invoice.js. Run it with no network and see what it did. Something that knows it’s in a sandbox can just behave nicely, so treat this as a first look.
> sbx detonate .\samples\Suspicious\suspicious.ps1 --network firewall
suspicious.ps1: 3 red flag(s) (watched 40s, network firewall)
created a scheduled task: ContosoUpdate
put something in a Startup folder: C:\Users\...\Start Menu\Programs\Startup\contoso.cmd
starts itself with Windows: HKCU\Software\Microsoft\Windows\CurrentVersion\Run\ContosoUpdater
looked up 1 internet name(s): c2.contoso-updates.example
tried to connect to 2 address(es): 198.51.100.7:4444, 203.0.113.10:80
…The MCP server
Add it to your agent, and your agent can use a Windows PC.
It works with GitHub Copilot, Claude, Cursor, VS Code and anything else that speaks MCP. The agent finds the 27 tools on its own, and screenshots come back inline so it can see what it did.
Your PC
sbx CLIWindows Sandbox
The CLI
Rather use a terminal? Use sbx.
You don’t have to use MCP. The server is an optional MCP adapter, and sbx uses the same engine, so all of this works from a shell, a script or an agent that can run commands.
# One shot
sbx run .\MyApp.exe --network off
sbx install-test setup.msi
sbx detonate invoice.js
# Keep one around while you work
sbx start --network off
sbx deploy .\bin C:\apps\MyApp --launch MyApp.exe --restart
sbx ui click --name Save
sbx shot
sbx stopsbx here is sandbox-mcp’s Windows Sandbox CLI. Docker also has its own sbx command for Docker Sandboxes.
Get it
Set it up.
You need Windows 11 24H2 or later on Pro, Enterprise or Education. Turn on Windows Sandbox in an admin PowerShell, restart, then open it from the Start menu once.
Enable-WindowsOptionalFeature -Online -FeatureName Containers-DisposableClientVM -AllLet your agent set it up.
It checks your PC and verifies the download, and it asks before admin changes or a restart. No Node.js install needed.
Give this to your agent
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.MCP and five skills, for your agent.
Needs Node.js 20 or later. The standalone CLI does not require this plugin.
Plugin guide, including VS Code
GitHub Copilot CLI
copilot plugin marketplace add shanselman/sandbox-mcp
copilot plugin install sandbox-mcp@sandbox-mcpFor the CLI. No Node.js install, MCP setup or PATH changes.
Everything’s in the ZIP, including its own Node.js. Install from source if you’d rather.
In the extracted folder
.\sbx.cmd doctor
.\sbx.cmd run C:\Windows\System32\charmap.exe --openWindows Sandbox
You probably already own it, and it’s probably switched off.
Windows Sandbox comes with Windows Pro, Enterprise and Education. It’s a whole Windows desktop on its own kernel that boots clean in about 15 seconds and is thrown away when it closes. Set network to off and it doesn’t even get a network adapter.
Your PC
Run folderThe sandbox can’t see the rest of your disk- →
agentread-only - →
inread-only, files you copy in - ←
outwritable, so don’t trust what comes back - ↔
controlencrypted, tied to one boot - ×Clipboard, printer, mic, cameraoff
Windows Sandbox
Its own kernelIsolated by the Microsoft hypervisorThis is strong isolation but not a guarantee, so use a dedicated machine for real malware analysis. Security notes.
Compatibility results
App types and packaging tested in Windows Sandbox.
| App type | Packaging | Result | Boot / total |
|---|---|---|---|
| WinForms | .NET Framework 4.8 EXE | PASS | 15.6 / 41.9 s |
| WinForms | .NET 10 self-contained EXE | PASS | 16.6 / 45.0 s |
| WPF | .NET 10 self-contained EXE | PASS | 16.7 / 45.6 s |
| Native Win32 | x64 EXE, static CRT | PASS | 16.1 / 41.6 s |
| Native Win32 | Dev-signed MSIX | PASS | 18.0 / 48.2 s |
| WinUI 3 | Self-contained EXE | PASS | 14.4 / 42.7 s |
| WinUI 3 | Dev-signed MSIX | PASS | 12.7 / 45.4 s |
These are specific builds, not a promise that every Windows app runs in Sandbox. Read the full compatibility notes.
Limits
What it won’t do.
- One sandbox at a time. That’s a Windows Sandbox rule. For many machines, persistence or Linux, use a VM.
- Needs a logged-in Windows x64 PC. Hosted CI runners can’t boot one.
- Not every Windows app. Anything that needs special hardware may not run.
- It won’t install prerequisites unless you ask. A missing one is usually the bug you’re looking for.