Summary
Code an assistant writes runs somewhere that is not your working directory.
The container boundary is the whole point: install a package, run a script, generate a file, and the mess stays inside a sandbox you can list and reuse. Output files come back as links rather than as blobs pasted into the conversation.
What it is
A Python execution sandbox exposed over MCP. Each sandbox is a Docker container with its own id; code, shell commands and package installs all run inside it, and files the code produces come back as web links.
What you get
- A fresh Docker sandbox created on demand, and the id you use for everything after
- Python executed inside that container, with the output returned
- Shell commands run in the same container
- Packages installed on request, and a check for whether one is already there
- Files uploaded into a sandbox before the code runs
- Existing sandboxes listed, so a later session can pick one up again
Requirements
Docker on the machine running the server, plus a recent Python and uv to start it. It listens on 127.0.0.1:8181 over SSE — localhost only until you change the host in config.toml. API-key authentication is available and off by default.