OpenSandbox is an Apache-2.0, Python-based general-purpose sandbox platform that gives AI-agent developers a unified sandbox API with Docker and Kubernetes runtimes plus multi-language SDKs, the osb CLI, and an MCP server.

What it is

OpenSandbox is a general-purpose sandbox platform for AI applications. It lives in the AI-agent infrastructure ecosystem, where its Kubernetes topic places it alongside container schedulers, and it ships multi-language SDKs, unified sandbox APIs, and Docker and Kubernetes runtimes for scenarios such as Coding Agents, GUI Agents, Agent Evaluation, AI Code Execution, and RL Training. The project defines a Sandbox Protocol covering sandbox lifecycle management APIs and sandbox execution APIs, which is what allows custom sandbox runtimes to be plugged in rather than forked. Built-in environments cover the Command, Filesystem, and Code Interpreter layers, and the documented examples reach out to Claude Code, Chrome, Playwright, VNC, and VS Code.

The concrete problem is that running model-generated code, browser automation, or desktop sessions requires safe isolation, dependable lifecycle management, controlled network access, and secret handling. OpenSandbox replaces the per-project plumbing that teams otherwise assemble by hand: creating and tearing down containers, executing commands, moving files, and injecting credentials into workloads. It centralises those concerns behind one protocol and one API surface, so the same sandbox can be created locally with Docker during development and scheduled at scale on Kubernetes for evaluation or reinforcement-learning training runs, without rewriting the agent side.

Key capabilities

• Multi-language SDKs for sandbox creation, command execution, and file operations: pip install opensandbox for Python, npm install @alibaba-group/opensandbox for JavaScript/TypeScript, dotnet add package Alibaba.OpenSandbox for C#/.NET, com.alibaba.opensandbox:sandbox for Gradle and Maven, and go get github.com/alibaba/OpenSandbox/sdks/sandbox/go.
• The osb CLI for the common workflow, installed through pip install opensandbox-cli or uv tool install opensandbox-cli, with commands including osb config init, osb config set connection.domain, osb sandbox create --image python:3.12 --timeout 30m -o json, and osb command run -o raw.
• An MCP server, installed with pip install opensandbox-mcp and started as opensandbox-mcp --domain localhost:8080 --protocol http, which exposes sandbox creation, command execution, and text file operations to MCP-capable clients such as Claude Code and Cursor.
• The Sandbox Protocol and its API specs in specs/README.md, which let third parties extend custom sandbox runtimes rather than only consume the built-in ones.
• Two runtimes under one lifecycle model: Docker for local execution and a high-performance Kubernetes runtime for large-scale distributed scheduling.
• Built-in Command, Filesystem, and Code Interpreter environments, with examples covering Coding Agents such as Claude Code, browser automation through Chrome and Playwright, and desktop environments through VNC and VS Code.
• Network Policy through a unified ingress gateway with multiple routing strategies plus per-sandbox egress controls, and a Credential Vault that injects credentials into sandbox outbound requests without exposing real secrets to workloads.
• Strong isolation options through secure container runtimes including gVisor, Kata Containers, and Firecracker microVMs.

Who uses it and how

• Teams building coding agents, where an agent such as Claude Code needs a disposable container to create, execute commands in, and read files from.
• Teams building GUI and browser agents that drive Chrome, Playwright, VNC, or VS Code sessions inside an isolated desktop environment.
• Groups running agent evaluation, AI code execution, and RL training workloads that need many sandboxes scheduled concurrently on Kubernetes rather than one container on a laptop.
• Developers who already use MCP-capable clients and want sandbox creation, command execution, and text file operations available through a stdio server configuration.
• Anyone moving between environments: Docker covers local runs, and the Kubernetes runtime carries the same workloads to distributed scheduling without changing the sandbox API.

Getting started

Install the server-side stack with Docker as a requirement and Python 3.10+ for examples and the local runtime, then add a client through pip install opensandbox, pip install opensandbox-cli, or pip install opensandbox-mcp. Release images are published under the same component name on Docker Hub at docker.io/opensandbox/, GitHub Container Registry at ghcr.io/opensandbox-group/opensandbox/, and Alibaba Cloud Container Registry at sandbox-registry.cn-zhangjiakou.cr.aliyuncs.com/opensandbox/, tagged releases signed keylessly with Cosign with provenance attestations, and production images pinned by digest and verified against the OpenSandbox GitHub Actions identity.

How it compares

The facts provided name no comparable products in this registry, so OpenSandbox stands alone in this listing rather than sitting beside named alternatives. The technologies it references in that space are layers underneath it, not substitutes: gVisor, Kata Containers, and Firecracker microVMs supply isolation, while Claude Code and Cursor are clients that connect through the MCP server. Ongoing activity is visible in the repository itself, with 15,381 stars, 1,407 forks, 132 open issues, and the most recent push in September 2026.

When to use it — and when not to

Adopting OpenSandbox means operating your own infrastructure: Docker for local execution, a Kubernetes cluster for distributed scheduling, and a sandbox server that must be installed and configured before any client works. It suits teams that need isolation guarantees and control over their own execution environment, and it is a poor fit for anyone who wants a fully managed service with no runtime to run, or who has no AI-agent, code-execution, or evaluation workload to place inside a sandbox. The main caveat is documentation depth: the README's getting-started section is truncated at the point of configuring the sandbox server, so a new self-hoster should expect to read the separate specs/README.md, CLI, MCP, ingress, egress, and credential-vault documents rather than rely on a single walkthrough.

pip install opensandbox

dependencies {
    implementation("com.alibaba.opensandbox:sandbox:{latest_version}")
}

<dependency>
    <groupId>com.alibaba.opensandbox</groupId>
    <artifactId>sandbox</artifactId>
    <version>{latest_version}</version>
</dependency>

npm install @alibaba-group/opensandbox

dotnet add package Alibaba.OpenSandbox

go get github.com/alibaba/OpenSandbox/sdks/sandbox/go

pip install opensandbox-cli
# or
uv tool install opensandbox-cli

osb config init
osb config set connection.domain localhost:8080
osb config set connection.protocol http
osb config set connection.api_key <your-api-key>
osb sandbox create --image python:3.12 --timeout 30m -o json
osb command run <sandbox-id> -o raw -- python -c "print(1 + 1)"

pip install opensandbox-mcp
opensandbox-mcp --domain localhost:8080 --protocol http

{
  "mcpServers": {
    "opensandbox": {
      "command": "opensandbox-mcp",
      "args": ["--domain", "localhost:8080", "--protocol", "http"]
    }
  }
}

uvx opensandbox-server init-config ~/.sandbox.toml --example docker

uvx opensandbox-server

# Show help
# uvx opensandbox-server -h

uv pip install opensandbox

import asyncio

from opensandbox import Sandbox
from opensandbox.models import WriteEntry

async def main() -> None:
    # 1. Create a sandbox from the alpine image
    sandbox = await Sandbox.create("alpine")

    try:
        # 2. Execute a shell command
        execution = await sandbox.commands.run("echo 'Hello OpenSandbox!'")
        print(execution.logs.stdout[0].text)

        # 3. Write a script file
        await sandbox.files.write_files([
            WriteEntry(
                path="/tmp/hello.sh",
                data="echo \"Hello $1\"\necho '2 + 2 =' $((2 + 2))",
                mode=755,
            )
        ])

        # 4. Read the file back
        content = await sandbox.files.read_file("/tmp/hello.sh")
        print(f"Content: {content}")

        # 5. Execute the script
        execution = await sandbox.commands.run("sh /tmp/hello.sh OpenSandbox")
        for log in execution.logs.stdout:
            print(log.text)

    finally:
        # 6. Cleanup the sandbox
        await sandbox.destroy()

if __name__ == "__main__":
    asyncio.run(main())