Sandbox for Agents

Agents get much more useful when they can run real commands; install packages, manipulate data, browse the web. That became clear within days of tinkering on a personal AI assistant (think OpenClaw).

The problem is that letting an agent run arbitrary commands directly on its host is less than ideal, so I wanted a sandbox environment where they could run pretty much anything, while reducing the attack surface.

So I built mcp-sandboxd: an MCP server that exposes a few tools - one of which runs commands inside an isolated environment, such as a Docker container or a Kubernetes pod.

The core idea is simple: each identifier (in my case, a conversation id) maps to a long-running sandbox. So instead of creating a new environment for every command, the agent keeps working inside the same one. That means it can install dependencies once, modify files, and build up state across multiple calls.

For example, a simple run_sandbox toolcall might look like this:

{
  "identifier": "conversation-123",
  "commands": [
    { "argv": ["apt-get", "update"] },
    { "argv": ["apt-get", "install", "-y", "playwright"] },
    { "argv": ["playwright", "screenshot", "https://johan.eliasson.xyz", "/artifacts/screenshot.png"] }
  ],
  "options": {
    "as_user": "root"
  }
}

identifier is the sandbox id - reuse it across calls to keep working in the same environment.

It also supports artifacts: files written to /artifacts inside a sandbox can be fetched over HTTP via the MCP server, which acts as a proxy.

This little server has covered my use-case for my assistant so far. I don’t expect it to grow in features, and I’d rather keep it small and focused on doing this one thing well.

If you find it useful, maybe give it a star! ⭐