An agent that can run code is far more capable and far more dangerous, and containerising it is the honest answer to that. What makes this one practical rather than theoretical is that three language runtimes and the usual command-line tools are already in the image, so the first task does not begin with twenty minutes of installs. Go execution is compiled with cgo disabled, which is why snippets that would otherwise need a toolchain still run.
An execution sandbox for agents, packaged as a Docker container. Three tools: run a shell command, run a code snippet in one of three languages, or install a package. Because it all happens inside the container, a bad command hits the container rather than your filesystem.
- `shell` runs a bash command with a `timeout` and a working directory, under safety controls
- `execute_code` runs a Python, Node.js or Go snippet, creating and cleaning up the temporary files itself and returning compilation as well as runtime errors
- `install_package` adds a dependency through `pip`, `npm` or go modules, with an optional version
- A prepared environment rather than a bare image: Ubuntu 22.04 with Python 3.13.3, Node.js 20.19.2 and Go 1.23.4, plus git, curl, wget, build-essential, jq, ripgrep, fd-find and htop
- Safety controls that come with the container — non-root execution, timeouts and concurrency limits
- Two transports: stdio for a local client, and SSE for HTTP deployment
Docker. A Makefile wraps the setup — `make quick-start` builds the container and runs it with SSE transport, and other targets handle the Claude Desktop config. For local development the project uses `uv sync` and runs the module directly, with `MCP_TRANSPORT=sse` to switch transport. The SSE endpoint is `http://localhost:8000/sse`. The server implements the MCP 2024-11-05 specification.
Run a container — pull the image and point your client at it