DEV Community

Deduped
Deduped

Posted on

Sandbox an MCP server for Claude Code with one line in .mcp.json

#security #mcp #claudecode #ai

A community MCP server runs with your full user permissions. If you add one to Claude Code and it turns out to be sloppy or malicious, it can read your SSH keys or write anywhere your account can. You can limit that without a container.

anthropic-experimental/sandbox-runtime ships a small CLI called srt. Per its README it uses native OS sandboxing (sandbox-exec on macOS, bubblewrap on Linux, and a dedicated local user account with network filtering on Windows) plus proxy-based network filtering, and it needs no Docker. It was built for Claude Code and is labeled a beta research preview, so config formats may change.

Install 

npm install -g @anthropic-ai/sandbox-runtime
Enter fullscreen mode Exit fullscreen mode

Try it on a plain command first

The README shows the idea with simple commands:

srt "curl anthropic.com"   # allowed by the network allowlist
srt "curl example.com"     # Connection blocked by network allowlist
srt "cat ~/.ssh/id_rsa"    # Operation not permitted
Enter fullscreen mode Exit fullscreen mode

Processes start with minimal access. Writes are denied everywhere unless you allow a path, and network access is denied unless you allow a domain. Reads are allowed by default, and you deny the sensitive regions.

Wrap an MCP server in .mcp.json

Without sandboxing, the filesystem server looks like this:

{
  "mcpServers": {
    "filesystem": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-filesystem"]
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

With sandboxing, move the original command into args and make srt the command:

{
  "mcpServers": {
    "filesystem": {
      "command": "srt",
      "args": ["npx", "-y", "@modelcontextprotocol/server-filesystem"]
    }
  }
}
Enter fullscreen mode Exit fullscreen mode

Set the rules

Create ~/.srt-settings.json:

{
  "filesystem": {
    "denyRead": [],
    "allowWrite": ["."],
    "denyWrite": ["~/sensitive-folder"]
  },
  "network": {
    "allowedDomains": [],
    "deniedDomains": []
  }
}
Enter fullscreen mode Exit fullscreen mode

Here the server can write only inside the current project, and ~/sensitive-folder is off limits. An empty allowedDomains list means no network at all, so add only the domains the server genuinely needs.

Confirm it works

Restart your agent and ask the MCP server to write a file into the denied folder. The README shows the expected result:

Error: EPERM: operation not permitted, open '/Users/ollie/sensitive-folder/test.txt'
Enter fullscreen mode Exit fullscreen mode

If you see that, the sandbox is doing its job. Also try a denied read such as .env files with denyRead: ["**/.env"] while allowRead is ["."]; the README notes the more specific deny stays in force.

Why both filesystem and network rules

The README is explicit that you need both. Without file isolation a compromised process can read your keys, and without network isolation it can send them out. Pair them.

Caveats

  • It is a beta research preview, so check the repo for newer config formats.
  • Sandboxing limits what the process can touch; it does not make a bad server trustworthy.
  • This walkthrough follows the README and we have not run it end to end.

The step-by-step version is on our use-case page: sandbox an MCP server with one line in .mcp.json. More tools in this area are listed in sandboxing AI agents.

Want the setup commands for 50 AI repos people actually ship with? Get the free AI Repos That Actually Ship pack: https://dedupedai.com/ship-pack/?utm_source=devto&utm_medium=article&utm_campaign=shippack

Get one email every Monday with the week's hottest AI repos and exactly how to use them: subscribe free at dedupedai.com

Top comments (1)

Collapse
 
botquests profile image
BotQuests •

The empty denyRead list in the example is worth calling out: blocking writes and network access still leaves local secrets readable. I'd test the policy with dummy secret files rather than real credentials, and include one allowed read/write plus one denied read/write so a completely broken server doesn't look like a successful sandbox. Also keep the MCP server's environment minimal, since filesystem rules don't remove secrets already passed in environment variables. Pinning the server package version makes those checks repeatable instead of testing a different release each time npx resolves it.