Skip to main content
mcpSource-backed

Microsandbox MCP Server for Claude

Connect Claude to Microsandbox microVMs for sandbox lifecycle, command execution, filesystem, volume, and metrics workflows.

Review first review before installing

Open the source and read safety notes before installing.

Citation facts

Source-backed facts for citing this resource, derived directly from the registry — also available as plain text for AI assistants.

Source URLs
https://docs.microsandbox.dev/getting-started/agents, https://github.com/superradcompany/microsandbox-mcp
Safety notes
Treat this as code-execution infrastructure. The MCP tools can create sandboxes, run commands and shell strings, write files, manage volumes, stop sandboxes, and remove sandbox resources., Use ephemeral sandboxes for untrusted or one-off commands. Persistent named sandboxes and volumes can retain code, logs, artifacts, package caches, and other state across sessions., Keep manual approval enabled for `sandbox_exec`, `sandbox_shell`, filesystem writes, volume changes, and sandbox removal until the workflow is well understood., Microsandbox documents host-controlled network policy and default defenses for private IP ranges, loopback, link-local addresses, cloud metadata endpoints, and DNS rebinding; review those defaults before allowing broad network access., Do not mount sensitive host paths or grant broad network egress to code you have not reviewed. The microVM boundary reduces host exposure, but it is not a reason to run arbitrary privileged workflows., Review any installer, runtime update, or image pull path before approving it in regulated or production environments.
Privacy notes
Commands, stdout, stderr, exit codes, file paths, file contents, sandbox names, image names, environment variables, metrics, and logs can be returned to the MCP client and model session., Files written inside a sandbox may persist when using named sandboxes, snapshots, or volumes. Remove temporary sandboxes and volumes when their artifacts are no longer needed., Secrets should stay in host-side secret management where possible. Microsandbox documents placeholder-based secret injection and host-restricted delivery; keep allowed hosts narrow., Networked code can still send permitted data to external services. Pair sandbox use with explicit egress rules for workflows that touch private source code, credentials, datasets, or customer data., Package installs, image pulls, and commands run inside the sandbox can contact third-party registries or services and may leave audit, billing, or telemetry records with those providers.
Author
Superrad Company
Submitted by
oktofeesh1
Claim status
unclaimed
Last verified
2026-06-03

Decision playbook

Review trust signals before you adopt

Signals are present but mixed. Use the checklist below to confirm the source and operational safety for your environment.

Compare context
Selected

0

Current score

78

Baseline

Delta

No baseline selected

No major trust-signal divergence detected in the current selection.

Source and provenance checks

Complete

Confirm ownership and provenance before trusting install instructions.

  • Source link availableRequired

    Open the canonical repository and verify ownership.

    Done
  • Source provenance statusRequired

    Marked as source-backed.

    Done
  • Metadata reviewed

    Registry metadata indicates a reviewed listing.

    Done

Safety and privacy checks

Complete

Validate risk disclosures before installation or API wiring.

  • Safety notes presentRequired

    Review the listed safety guidance before running commands.

    Done
  • Privacy notes presentRequired

    Review data handling notes before connecting accounts or secrets.

    Done
  • Trust level risk gateRequired

    Trust level does not block evaluation.

    Done

Package and install checks

Needs review

Check package metadata and artifact integrity signals.

  • Install payload available

    Install or copy payload is available for review.

    Done
  • Package verification flag

    No package verification flag provided.

    Pending
  • Checksum metadata

    No checksum provided for downloaded artifact.

    Pending

Compare-driven decision checks

Needs review

Use compare context to validate trade-offs before adoption.

  • Compare tray has multiple entries

    Add at least one more entry to compare trust differences.

    Pending
  • Baseline comparison available

    No baseline peer selected yet.

    Pending
  • Diverging trust signals identified

    No major trust-signal divergence found.

    Pending

Setup at a glance

CLI install

Copy-ready — paste the snippet to get started.

10 minutes

Adoption plan

Balanced adoption plan

Current risk score 16/100. Use staged verification before broader rollout.

Risk 16

Pre-adoption checks

Validate source and review signals before any execution.

  • Confirm source provenanceRequired

    Source URL/provenance metadata is present.

    Done
  • Confirm metadata review state

    Listing has review metadata.

    Done
  • Verify install payload

    Install/config payload exists and can be inspected.

    Done

Security checks

Confirm safety, privacy, and package integrity signals.

  • Review safety notesRequired

    Safety notes are present.

    Done
  • Review privacy notesRequired

    Privacy notes are present.

    Done
  • Verify package integrity metadata

    No package verification/checksum metadata.

    Pending

Rollout

Adopt in controlled steps based on the selected plan.

  • Run in isolated sandbox firstRequired

    Use a constrained sandbox and observe behavior across multiple tasks.

    Pending
  • Roll out graduallyRequired

    Roll out to a small cohort before wider usage.

    Pending
  • Set monitoring and fallback

    Define rollback path and monitor errors after adoption.

    Pending

Evidence readiness

Evidence readiness matrix · balanced

Required evidence gates are covered (5/6 signals complete).

Risk 15

Source provenance

Present

Source repository/provenance is listed.

Required in this preset

Metadata review

Present

Review metadata is present.

Required in this preset

Safety notes

Present

Safety notes are present.

Required in this preset

Privacy notes

Present

Privacy notes are present.

Optional in this preset

Package integrity

Missing

Package integrity metadata is missing.

Optional in this preset

Install payload

Present

Install payload is available.

Required in this preset

Required evidence gates are covered for this preset.

Decision timeline

Decision timeline · balanced

5/6 steps complete with no blocking gaps for this preset.

Risk 14

triage

Confirm source provenanceRequired

Source/provenance metadata is available.

Done

triage

Check metadata review statusRequired

Review metadata is available.

Done

verify

Review safety notesRequired

Safety notes are available.

Done

verify

Review privacy notes

Privacy notes are available.

Done

verify

Validate package integrity metadata

Package integrity metadata is missing.

Pending

rollout

Verify install payload and commandsRequired

Install payload is available.

Done

No required blockers for this timeline preset.

Prerequisite readiness

Prerequisite readiness

6 prerequisites to line up before setup.

0/6 ready
Install & runtime1Permissions & scopes1Network & hosting3General110 minutes

Safety & privacy surface

Safety & privacy surface

6 safety and 5 privacy notes across 5 risk areas. Review closely: credentials & tokens, permissions & scopes, network access, third-party handling.

5 areas
  • SafetyLocal filesTreat this as code-execution infrastructure. The MCP tools can create sandboxes, run commands and shell strings, write files, manage volumes, stop sandboxes, and remove sandbox resources.
  • SafetyCredentials & tokensUse ephemeral sandboxes for untrusted or one-off commands. Persistent named sandboxes and volumes can retain code, logs, artifacts, package caches, and other state across sessions.
  • SafetyLocal filesKeep manual approval enabled for `sandbox_exec`, `sandbox_shell`, filesystem writes, volume changes, and sandbox removal until the workflow is well understood.
  • SafetyNetwork accessMicrosandbox documents host-controlled network policy and default defenses for private IP ranges, loopback, link-local addresses, cloud metadata endpoints, and DNS rebinding; review those defaults before allowing broad network access.
  • SafetyPermissions & scopesDo not mount sensitive host paths or grant broad network egress to code you have not reviewed. The microVM boundary reduces host exposure, but it is not a reason to run arbitrary privileged workflows.
  • SafetyLocal filesReview any installer, runtime update, or image pull path before approving it in regulated or production environments.
  • PrivacyCredentials & tokensCommands, stdout, stderr, exit codes, file paths, file contents, sandbox names, image names, environment variables, metrics, and logs can be returned to the MCP client and model session.
  • PrivacyLocal filesFiles written inside a sandbox may persist when using named sandboxes, snapshots, or volumes. Remove temporary sandboxes and volumes when their artifacts are no longer needed.
  • PrivacyCredentials & tokensSecrets should stay in host-side secret management where possible. Microsandbox documents placeholder-based secret injection and host-restricted delivery; keep allowed hosts narrow.
  • PrivacyCredentials & tokensNetworked code can still send permitted data to external services. Pair sandbox use with explicit egress rules for workflows that touch private source code, credentials, datasets, or customer data.
  • PrivacyThird-party handlingPackage installs, image pulls, and commands run inside the sandbox can contact third-party registries or services and may leave audit, billing, or telemetry records with those providers.

Safety notes

  • Treat this as code-execution infrastructure. The MCP tools can create sandboxes, run commands and shell strings, write files, manage volumes, stop sandboxes, and remove sandbox resources.
  • Use ephemeral sandboxes for untrusted or one-off commands. Persistent named sandboxes and volumes can retain code, logs, artifacts, package caches, and other state across sessions.
  • Keep manual approval enabled for `sandbox_exec`, `sandbox_shell`, filesystem writes, volume changes, and sandbox removal until the workflow is well understood.
  • Microsandbox documents host-controlled network policy and default defenses for private IP ranges, loopback, link-local addresses, cloud metadata endpoints, and DNS rebinding; review those defaults before allowing broad network access.
  • Do not mount sensitive host paths or grant broad network egress to code you have not reviewed. The microVM boundary reduces host exposure, but it is not a reason to run arbitrary privileged workflows.
  • Review any installer, runtime update, or image pull path before approving it in regulated or production environments.

Privacy notes

  • Commands, stdout, stderr, exit codes, file paths, file contents, sandbox names, image names, environment variables, metrics, and logs can be returned to the MCP client and model session.
  • Files written inside a sandbox may persist when using named sandboxes, snapshots, or volumes. Remove temporary sandboxes and volumes when their artifacts are no longer needed.
  • Secrets should stay in host-side secret management where possible. Microsandbox documents placeholder-based secret injection and host-restricted delivery; keep allowed hosts narrow.
  • Networked code can still send permitted data to external services. Pair sandbox use with explicit egress rules for workflows that touch private source code, credentials, datasets, or customer data.
  • Package installs, image pulls, and commands run inside the sandbox can contact third-party registries or services and may leave audit, billing, or telemetry records with those providers.

Prerequisites

  • macOS on Apple Silicon, or Linux on x86_64 or ARM64 with KVM support
  • Node.js 22+ and npm/npx for running the `microsandbox-mcp` package
  • MCP-capable client with stdio transport, such as Claude Code, Claude Desktop, Cursor, VS Code, Windsurf, OpenCode, or Zed
  • Permission to install and run the Microsandbox `msb` runtime and `libkrunfw` on the host
  • Disk space for sandbox images, writable layers, snapshots, and named volumes
  • A clear policy for what code Claude may run and what files, network destinations, secrets, and volumes those sandboxes may access

Schema details

Install type
cli
Troubleshooting
Yes
Source repository stats
Scope
Source repo
Collection metadata
Estimated setup
10 minutes
Difficulty
intermediate
Full copyable content
{
  "microsandbox": {
    "command": "npx",
    "args": ["-y", "microsandbox-mcp"]
  }
}

About this resource

Content

The Microsandbox MCP server exposes the Microsandbox runtime to Claude and other MCP-capable clients over stdio. It gives agents structured tools for creating microVM sandboxes, running commands inside them, reading and writing sandbox files, managing named volumes, and inspecting resource metrics.

This entry is for workflows where Claude needs an isolated execution target, not direct access to the host shell. The practical safety boundary still depends on how the sandbox is configured: what image it uses, whether it is ephemeral or persistent, which volumes are attached, which secrets are available, and what network policy is active.

Microsandbox documents the MCP server in its AI agents guide, publishes the server as the microsandbox-mcp npm package, and maintains the source in the superradcompany/microsandbox-mcp repository.

Features

  • Stdio MCP server installable with npx -y microsandbox-mcp.
  • Sandbox lifecycle tools for creating, listing, inspecting, stopping, and removing sandboxes.
  • Ephemeral sandbox_run tool for creating a sandbox, running a command, and cleaning it up.
  • Command execution tools for command-plus-args execution and shell-string execution inside an existing sandbox.
  • Filesystem tools for reading, writing, listing, creating, removing, and statting files inside the sandbox filesystem.
  • Named volume tools for creating, listing, and removing persistent volumes.
  • Metrics tools for live CPU, memory, disk I/O, and network visibility.
  • Runtime installation check for the local msb runtime and libkrunfw.
  • Client examples for Claude Code, Claude Desktop, Cursor, VS Code, Windsurf, OpenCode, Zed, and other stdio-capable MCP clients.
  • Microsandbox runtime support for macOS on Apple Silicon and Linux on x86_64 or ARM64 with KVM support.

Use Cases

  • Give Claude a disposable microVM for running untrusted snippets, tests, or package experiments without handing it the host shell directly.
  • Run commands in a known sandbox image while keeping stdout, stderr, and exit codes available to the agent.
  • Let Claude inspect or edit files inside a sandboxed workspace before copying only approved artifacts back into a project.
  • Create persistent sandboxes for repeatable debugging sessions that need state across multiple tool calls.
  • Attach named volumes when a workflow needs cached dependencies or reusable data between sandbox runs.
  • Monitor CPU, memory, disk I/O, and network metrics for long-running sandboxed tasks.
  • Test code that needs outbound internet access while relying on Microsandbox's host-controlled network policy for local-network and metadata-endpoint boundaries.

Installation

Claude Code

  1. Confirm Node.js 22+ is installed:
node --version
  1. Add the stdio MCP server:
claude mcp add --transport stdio microsandbox -- npx -y microsandbox-mcp
  1. Start a fresh Claude Code session and inspect the available Microsandbox tools before approving any execution request.
  2. Run the check_installed tool first. If the host runtime is missing, follow the Microsandbox installation docs for the msb runtime and libkrunfw.

Claude Desktop

  1. Open the Claude Desktop MCP configuration file.
  2. Add the microsandbox server configuration shown below.
  3. Restart Claude Desktop.
  4. Start with low-risk prompts such as checking whether the runtime is installed or creating a short-lived sandbox for a simple command.

Configuration

{
  "mcpServers": {
    "microsandbox": {
      "command": "npx",
      "args": ["-y", "microsandbox-mcp"]
    }
  }
}

For clients that expect the server object directly, use the same command and arguments:

{
  "microsandbox": {
    "command": "npx",
    "args": ["-y", "microsandbox-mcp"]
  }
}

Examples

Check the runtime

Ask Claude to verify that the local Microsandbox runtime is available before running any sandboxed code.

Check whether Microsandbox is installed and report what runtime pieces are missing.

Run an ephemeral command

Use an ephemeral sandbox when the task does not need state after the command finishes.

Create a temporary Microsandbox Python sandbox, run a hello-world command, return stdout and stderr, and clean up the sandbox afterward.

Inspect sandbox state

Use lifecycle and metrics tools for a persistent sandbox during a debugging session.

List the running Microsandbox sandboxes, inspect the one named "agent-test", and show current CPU, memory, disk I/O, and network metrics.

Work with sandbox files

Keep file operations scoped to the sandbox filesystem.

Create a file inside the sandbox, run a command that reads it, then show me the output and the final file metadata.

Best Practices

  • Prefer sandbox_run for disposable tasks that should not keep state.
  • Use persistent sandboxes only when the workflow genuinely needs continuity.
  • Name sandboxes and volumes clearly so cleanup decisions are obvious.
  • Keep network access narrow for workflows involving private code, credentials, datasets, or customer data.
  • Review shell-string commands before approval because sandbox_shell supports pipes, redirects, and shell syntax.
  • Avoid passing secrets as command arguments or prompts. Use the Microsandbox secret-injection model and narrow allowed hosts when secrets are required.
  • Clean up unused sandboxes and volumes after each workflow.
  • Treat output from sandboxed code as untrusted input, especially when it comes from downloaded packages, web content, tests, or generated files.

Troubleshooting

Runtime check reports missing components

Run the MCP check_installed tool first, then follow the Microsandbox install docs for the host operating system. Linux hosts need KVM support; macOS support is for Apple Silicon.

Sandbox creation fails

Confirm the host platform is supported, the runtime is installed, the user has permission to run it, and there is enough disk space for images and writable layers.

Commands hang or produce no output

Use explicit command arguments where possible, add a timeout, and inspect stdout, stderr, and the exit code. For shell syntax, confirm the target image has the expected shell and binaries installed.

Network access is blocked

Review the Microsandbox networking docs and the active sandbox policy. The default network model is designed to prevent workloads from reaching private network ranges, loopback, link-local addresses, cloud metadata endpoints, and DNS rebinding targets.

Files disappear between runs

Ephemeral sandboxes are meant to be disposable. Use a persistent named sandbox, snapshot, or named volume only when retaining state is intentional.

Related Links

Source citations

Add this badge to your README

Show that Microsandbox MCP Server for Claude is listed on HeyClaude. Paste this Markdown into your README — it renders the badge and links back to this page.

Listed on HeyClaude
[![Listed on HeyClaude](https://heyclau.de/badge/mcp/microsandbox-mcp-server.svg)](https://heyclau.de/entry/mcp/microsandbox-mcp-server)

How it compares

Microsandbox MCP Server for Claude side by side with 2 alternatives on trust, install, platform support, and disclosed safety notes — all from reviewed registry metadata.

1 trust signal differ across this comparison (Submitter).

Field

Connect Claude to Microsandbox microVMs for sandbox lifecycle, command execution, filesystem, volume, and metrics workflows.

Open dossier

Official MathWorks MCP server that lets Claude detect MATLAB installations, inspect toolboxes, analyze MATLAB files, evaluate MATLAB code, run scripts, run tests, and expose reviewed custom MATLAB functions as MCP tools.

Open dossier

Initialize projects, trigger task runs, deploy to environments, and monitor execution from Claude — with the official Trigger.dev MCP server for background job and AI agent workflow orchestration.

Open dossier
Next steps
Trust
Review statusReviewedMaintainer reviewedReviewedMaintainer reviewedReviewedMaintainer reviewed
Package trustPackage not verifiedPackage not verifiedPackage not verified
Source provenanceSource-backedSource-backedSource-backed
SubmitterDiffersoktofeesh1oktofeesh1
Install riskReview firstReview firstReview first
Notes Safety ✓ Privacy ✓ Safety ✓ Privacy ✓ Safety ✓ Privacy ✓
BrandMATLAB logoMATLABTrigger.dev logoTrigger.dev
Categorymcpmcpmcp
SourceSource-backedSource-backedSource-backed
AuthorSuperrad CompanyMathWorksTrigger.dev
Added2026-06-032026-06-062026-06-18
Platforms
Harness
Source repo
Safety notesTreat this as code-execution infrastructure. The MCP tools can create sandboxes, run commands and shell strings, write files, manage volumes, stop sandboxes, and remove sandbox resources. Use ephemeral sandboxes for untrusted or one-off commands. Persistent named sandboxes and volumes can retain code, logs, artifacts, package caches, and other state across sessions. Keep manual approval enabled for `sandbox_exec`, `sandbox_shell`, filesystem writes, volume changes, and sandbox removal until the workflow is well understood. Microsandbox documents host-controlled network policy and default defenses for private IP ranges, loopback, link-local addresses, cloud metadata endpoints, and DNS rebinding; review those defaults before allowing broad network access. Do not mount sensitive host paths or grant broad network egress to code you have not reviewed. The microVM boundary reduces host exposure, but it is not a reason to run arbitrary privileged workflows. Review any installer, runtime update, or image pull path before approving it in regulated or production environments.MATLAB MCP Core Server can start MATLAB, connect to an existing MATLAB instance, evaluate arbitrary MATLAB code, run scripts, and run MATLAB test files. The evaluate and run tools can change files, workspace state, figures, models, generated artifacts, or external systems depending on the MATLAB code being executed. Custom extension files can expose additional MATLAB functions as MCP tools, so review the JSON definition and the corresponding MATLAB functions before startup. The README advises reviewing all tool calls and keeping a human in the loop before running important actions. Shared or centralized server use is restricted by upstream licensing guidance; check MathWorks terms before team or service deployments.The MCP server can trigger task runs and deploy code to production environments — review Claude's proposed actions before confirming. The `search_docs` tool works without authentication; all other tools require CLI login. Triggered runs incur usage against your Trigger.dev plan; be mindful when using bulk trigger operations.
Privacy notesCommands, stdout, stderr, exit codes, file paths, file contents, sandbox names, image names, environment variables, metrics, and logs can be returned to the MCP client and model session. Files written inside a sandbox may persist when using named sandboxes, snapshots, or volumes. Remove temporary sandboxes and volumes when their artifacts are no longer needed. Secrets should stay in host-side secret management where possible. Microsandbox documents placeholder-based secret injection and host-restricted delivery; keep allowed hosts narrow. Networked code can still send permitted data to external services. Pair sandbox use with explicit egress rules for workflows that touch private source code, credentials, datasets, or customer data. Package installs, image pulls, and commands run inside the sandbox can contact third-party registries or services and may leave audit, billing, or telemetry records with those providers.Tool calls can expose MATLAB code, command-window output, project folder names, installed toolbox versions, add-ons, scripts, tests, model outputs, plots, logs, and local file paths. The README states anonymized usage data collection is on by default and can be disabled with `--disable-telemetry=true`. Log folders, stderr duplication, extension-file paths, MATLAB roots, and initial working folders can reveal local machine or project context. If MATLAB code calls external services, reads private data, or writes generated outputs, those effects are part of the approved tool call and may be visible to the MCP client and model provider.Project configurations, task definitions, run histories, and dashboard metrics from your Trigger.dev workspace are surfaced in Claude's context. Authentication uses the Trigger.dev CLI session token stored locally — no credentials are embedded in the MCP server configuration.
Prerequisites
  • macOS on Apple Silicon, or Linux on x86_64 or ARM64 with KVM support
  • Node.js 22+ and npm/npx for running the `microsandbox-mcp` package
  • MCP-capable client with stdio transport, such as Claude Code, Claude Desktop, Cursor, VS Code, Windsurf, OpenCode, or Zed
  • Permission to install and run the Microsandbox `msb` runtime and `libkrunfw` on the host
  • MATLAB R2021a or later installed under a valid MathWorks license.
  • Claude Code, Claude Desktop, VS Code, or another MCP client that can run a local stdio server.
  • Release binary, source build, or Claude Desktop MCPB bundle downloaded from the upstream repository.
  • Project folders and MATLAB files reviewed before allowing Claude to run code against them.
  • A Trigger.dev account — log in via the CLI when prompted (`npx trigger.dev@latest login`).
  • Node.js 18+ for `npx`.
  • An MCP client such as Claude Code or Claude Desktop.
Install
claude mcp add --transport stdio microsandbox -- npx -y microsandbox-mcp
Download the release binary or Claude Desktop MCPB bundle, review the MathWorks license terms, then add the stdio server command to your MCP client.
npx trigger.dev@latest install-mcp --client claude-code
Config
{
  "mcpServers": {
    "microsandbox": {
      "command": "npx",
      "args": ["-y", "microsandbox-mcp"]
    }
  }
}
{
  "mcpServers": {
    "matlab": {
      "command": "{path-to-matlab-mcp-core-server}",
      "args": [
        "--disable-telemetry=true",
        "--initial-working-folder={project-folder}"
      ]
    }
  }
}
{
  "mcpServers": {
    "trigger": {
      "command": "npx",
      "args": ["trigger.dev@latest", "mcp"]
    }
  }
}
Citations
ClaimUnclaimedUnclaimedUnclaimed
Open 3 picks in the interactive comparison tool

Related guides

Signals

Loading live community signals…

More like this, weekly

A short, calm digest of reviewed Claude resources. Unsubscribe any time.