Exec Sandbox

Single exec tool running caller Python in a network-isolated locked-down sandbox.

OtherGov0.5.4

mcp-exec

English | Русский

Version MCP Registry Docker Pulls Docker Image Version Build Go Version Go Report Card License: MIT Issues Last Commit

Public OSS MCP server (Go, MIT) exposing a single powerful tool — exec — that runs caller-supplied Python code in a network-isolated, locked-down sandbox and returns stdout / stderr / exit_code. It is the "code-execution mode" building block: instead of flooding an agent's context with hundreds of tool schemas, the agent writes code that orchestrates the work.

Works over three transports — stdio / HTTP / SSE — with an identical tool set everywhere (official modelcontextprotocol/go-sdk).

The exec tool

Input: { code: string (required), timeout_s?: int, stdin?: string } Output: { stdout, stderr, exit_code, duration_ms, truncated, timed_out }

  • A non-zero exit_code or timed_out=true is a normal result, not a tool error. Only invalid input (empty code, oversized stdin) is a tool-call error.
  • Sandbox v1: Python 3 with stdlib + PyYAML, Jinja2, Pillow, numpy, pandas, matplotlib.

Security model (invariants)

Per execution: no network, non-root, cap-drop=ALL, no-new-privileges, read-only rootfs, no CAP_SYS_ADMIN, ephemeral tmpdir (cleaned up), wall-clock timeout (kills the whole process-group), memory/PID/CPU limits, capped output (1 MiB → truncated). Runs are serialized within an instance; scale out with replicas. Caller data (code/stdin/output) is never persisted and never logged in full — only metadata.

exec is the most powerful surface there is. When embedding it in an agent, gate it behind that agent's tool-policy (trusted roles only).

Network note: --network none only applies to stdio. In HTTP/SSE the container needs networking to serve its port, so sandboxed code would inherit egress — deny it at the orchestrator. In k8s, a NetworkPolicy that allows ingress to the port and denies all egress:

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata: { name: mcp-exec-lockdown }
spec:
  podSelector: { matchLabels: { app: mcp-exec } }
  policyTypes: [Ingress, Egress]
  ingress: [{ ports: [{ port: 8080 }] }]
  egress: []   # deny all egress → sandbox has no network

Run

go build -o mcp-exec ./cmd/mcp-exec
MCP_EXEC_TRANSPORT=stdio ./mcp-exec

Docker (recommended production posture):

docker run --rm -i --network none --read-only --cap-drop ALL \
  --security-opt no-new-privileges --user 65532:65532 \
  --tmpfs /tmp:rw,noexec,nosuid,size=64m \
  --memory 256m --pids-limit 128 --cpus 1 \
  idconstruct/mcp-exec

--tmpfs /tmp is required: the rootfs is read-only, and each run needs a writable ephemeral workspace (cleaned up after).

Optional auth (HTTP/SSE)

Set MCP_EXEC_AUTH_TOKEN to require every HTTP/SSE request to carry a matching X-MCP-AUTH header (constant-time compare; 401 otherwise). Empty token disables it. Not applicable to stdio.

Configuration

Env varPurposeDefault
MCP_EXEC_TRANSPORTstdio | http | ssestdio
MCP_EXEC_ADDRlisten address for http/sse:8080
MCP_EXEC_DEFAULT_TIMEOUT_Sdefault wall-clock timeout30
MCP_EXEC_MAX_TIMEOUT_Stimeout ceiling300
MCP_EXEC_MAX_OUTPUT_BYTEScombined stdout+stderr cap1048576
MCP_EXEC_MAX_STDIN_BYTESstdin size cap1048576
MCP_EXEC_PYTHONinterpreter pathpython3
MCP_EXEC_AUTH_TOKENif set, http/sse require X-MCP-AUTH header (constant-time); empty = off``

Not in v1

bash / multi-language, network from the sandbox, proxying other MCP servers into the sandbox.

License

MIT.

Installation

Source-derived launch command. Check the maintainer’s required arguments and credentials before running:

bash
docker run -i --rm docker.io/idconstruct/mcp-exec:v0.5.4

Set up in your AI client

Merge this template into ~/Library/Application Support/Claude/claude_desktop_config.json. Keep existing servers. Add any arguments, credentials, and permissions required by the maintainer; this template has not been install-tested.

json
{
  "mcpServers": {
    "io-github-inhuman-mcp-exec": {
      "command": "docker",
      "args": [
        "run",
        "-i",
        "--rm",
        "docker.io/idconstruct/mcp-exec:v0.5.4"
      ]
    }
  }
}

Restart Claude Desktop completely for changes to take effect. Confirm the server appears connected in the client’s tool list, then try a read-only example from its documentation.

Claude Desktop setup reference

Package

docker.io/idconstruct/mcp-exec:v0.5.4docker

Compatible MCP Clients

Exec Sandbox works with any MCP-compatible client. Copy the config snippet from the Configuration section above and add it to the file shown for your client, then restart the application.

  • Claude Desktop~/Library/Application Support/Claude/claude_desktop_config.jsonRestart Claude Desktop completely for changes to take effect.
  • Cursor~/.cursor/mcp.jsonRestart Cursor for changes to take effect.
  • VS Code.vscode/mcp.jsonReload VS Code window for changes to take effect.
  • Windsurf~/.codeium/windsurf/mcp_config.jsonRestart Windsurf for changes to take effect.
  • Claude Code.mcp.jsonSave at the project root, then start Claude Code in that project and review the MCP server approval prompt. Keep real credentials out of shared files.

Learn More