Skip to content
Conduit

mcp server

windows-sandbox-mcp

Give AI coding agents a disposable Windows desktop. Commands, GUI automation, browser DOM control and screenshots over MCP. Tested on Windows 10 Pro.

xxmisaoxx/windows-sandbox-mcpcommunitylistedunreviewed

Set up

Runs on your computer. Pick your agent and operating system.

Before you start

  • uv (`curl -LsSf https://astral.sh/uv/install.sh | sh`)
~/Library/Application Support/Claude/claude_desktop_config.json
{
  "mcpServers": {
    "windows-sandbox-mcp": {
      "command": "uvx",
      "args": [
        "winsandbox-mcp"
      ]
    }
  }
}

same format Cursor, GitHub Copilot CLI, Junie, JetBrains AI Assistant, Augment (Auggie CLI), Factory Droid, Kiro, Devin CLI +12

Values in angle brackets are placeholders. Restart Claude Desktop after editing its config.Claude Desktop docs

README

synced Oct 28, 2026

Let Codex, OpenCode, and other local MCP clients work inside Windows Sandbox: run test commands, interact with desktop applications, automate compatible browser pages, and bring screenshots and files back to the agent.

  • Run Windows commands with stdout, stderr, exit codes, and timeouts.
  • Use the desktop with native control inspection, mouse input, Unicode text, and shortcuts.
  • Work with browser forms through optional guest-local DOM snapshots and actions.
  • Verify what happened with fresh observations, PNG screenshots, and hashed artifacts.

Tested on Windows 10 Pro 22H2 x64. Windows 11 support is being evaluated; it is not yet certified. Compatibility details →

See it working

An actual MCP run, using a synthetic offline page. The client discovers a field, fills it with MCP-DOM-OK, reads the value back, clicks Apply, and verifies the changed button state before retrieving the screenshot. No account or external web service is involved. Capture details.

Reproduce this demo after installation, with no other Sandbox open:

.venv\Scripts\python.exe scripts\check-mcp-live.py

The runner also checks guest commands, binary transfer, native UIA3 inspection, CDP opt-in enforcement, and native MCP image/resource retrieval. It closes its Sandbox when finished. The page is included in examples/browser-demo.html.

Quick start

You need Windows 10 Pro 22H2 x64, an interactive desktop, Windows Sandbox and virtualization enabled, Git, Python 3.11+, and uv. Run the server as a normal user. Close any manually opened Sandbox first.

git clone https://github.com/xxmisaoxx/windows-sandbox-mcp.git
cd windows-sandbox-mcp
uv sync --frozen
.venv\Scripts\python.exe -m winsandbox_mcp --doctor

This installs from source using the committed dependency lock. The doctor command reports host prerequisites; installation alone does not start a Sandbox. Next, connect your agent below. Full setup and troubleshooting →

Connect your agent

OpenCode

From the repository directory:

.venv\Scripts\python.exe scripts\install-opencode.py
opencode mcp list

The helper adds windows_sandbox, preserves other OpenCode settings, and backs up an existing config before changing it. Restart an existing OpenCode session to load the tools. Manual configuration.

Codex

Generate a configuration with the absolute paths of your checkout:

.venv\Scripts\python.exe scripts\client-configs.py
Get-Content .runtime\client-configs\codex-config.toml

Copy the generated [mcp_servers.windows_sandbox] entry into your ~/.codex/config.toml, preserving your existing settings. Reload Codex and check the server in /mcp. Configuration details.

Your first task

Ask your agent:

Use the windows_sandbox MCP to start a Sandbox, run a command that prints the Windows version, open Notepad, and type “Hello from my agent”. Read the text back to verify it, retrieve and show me a screenshot, then stop the Sandbox. Keep application execution and desktop interaction inside the guest.

The MCP server stays local and speaks stdio. Your agent's usual permissions and model access still apply. You do not need a separate API key for this server.

18 tools, one desktop workflow

Observe → act → observe again. A successful input call means input was submitted; a fresh inspection or screenshot verifies the application result.

WorkflowTools
Create and recover a desktopsandbox_doctor, sandbox_start, sandbox_status, sandbox_restart, sandbox_stop
Run commands and launch appssandbox_exec, sandbox_launch
Inspect and operate native appssandbox_windows, sandbox_inspect, sandbox_click, sandbox_text, sandbox_keys
Work with compatible web pagessandbox_browser
Transfer filessandbox_upload, sandbox_download
Capture and retrieve evidencesandbox_screenshot, sandbox_artifact, sandbox_collect_evidence

Native inspection supports UIA3, managed UIA2, MSAA with optional IA2-role queries, and Win32 controls. Inspection runs in a killable guest worker so a stuck provider can time out without hanging the main agent.

For Chromium/Electron, sandbox_launch(accessibility=true) enables the renderer accessibility flag on a fresh launch. Opt into a guest debug port to use sandbox_browser for DOM snapshots, fill, and click. This backend covers ordinary main-frame DOM; Firefox, closed shadow roots, canvas, and cross-origin frames need another path. GUI examples and limits →

Tested beyond the happy path

VerificationRecorded result
Automated tests on Windows 1089 passed, 1 skipped for unavailable symlink privilege
Live Windows Sandbox integration13 steps passed, including crash recovery and restart
Real MCP stdio clientCommands, native GUI inspection, DOM actions, file transfer, PNG images, and binary resources passed
Client connectionsCodex discovered all 18 tools; OpenCode connected
Hung accessibility providerWorker terminated; the guest agent remained usable

These are recorded runs on the documented Windows 10 machine, not a guarantee for every Windows build or application. GitHub Actions runs unit/protocol, lint, helper compilation, and packaging checks; it does not start a real Sandbox. Reproduce the checks and inspect the measurements →

Isolation you can inspect

The host uses the official Python MCP SDK. The guest uses built-in Windows PowerShell 5.1, .NET Framework, Win32, and UI Automation. GUI observation and input happen inside the guest. There is no host desktop automation fallback.

DefaultBehavior
Networking and redirectionNetworking, vGPU, clipboard, printer, audio input, and video input disabled
Host folder exposureOnly generated read-only inbox and dedicated writable outbox mapped
CommunicationBounded JSON mailbox; no host bridge listener or guest-to-host execution dispatcher
Guest runtimeNo host Python mapping or runtime guest package downloads
ArtifactsHost-owned copies with SHA-256 metadata; files limited to 4 MiB per transfer

Early development. One Sandbox per interactive Windows session. The writable outbox has no enforced disk quota and can fill its host volume; use quota-limited disposable storage for hostile workloads. Opting into networking permits normal host/LAN access. Stopping the guest discards its disk, while host artifacts and retained requests remain. Some longer test sessions showed increased latency. Read the security model, audit, and architecture before running untrusted workloads.

Help shape the next version

The next priorities are Windows 11 lifecycle support, portable GUI fixtures, and better performance in long sessions. Reproducible reports and focused fixes are welcome. Contributing · Report a bug · Request a feature

If a disposable Windows desktop would help your agent, star the repo to follow its progress. Try the demo and tell us what you want to automate next.

Released under the MIT license.

↑↓ navigate openesc close