OpenSandbox Runtime
An extensible isolated runtime for AI applications to create sandboxes, run commands, and manage files through unified interfaces.
- Source repo
- opensandbox-group/OpenSandbox
- Stars
- ★ 16k
- Last updated
- today
- License
- Apache-2.0
- Primary language
- Python
- FA score
- 47/100 · Major gaps
At a glance
- How it runs
- Works with
- Universal · cross-platformCodex · Claude Code
- Cost
- Free, no paid service needed
- Setup effort
- Medium · a few setup steps
- You'll need
- Typical use
- A developer-platform team needs short-lived isolated environments for a code-execution service on Docker or Kubernetes.
- Not a fit if
- Teams without Docker or Python 3.10+ locally
- Users who want a fully managed hosted service
- Teams unwilling to operate Kubernetes or sandbox servers
- Source review
- 47/100 · Major gaps
What does this agent do, and when should you use it?
OpenSandbox is a general-purpose sandbox platform for AI applications with unified APIs for sandbox lifecycle management, command execution, and file operations. The repository includes multi-language SDKs, the osb CLI, an MCP server, a Python FastAPI lifecycle server, and Docker and Kubernetes runtimes. Its built-in environments cover Command, Filesystem, and Code Interpreter, while examples address browser automation, desktop environments, coding CLIs, evaluation, and training. Workloads run inside sandboxes, with execution logs and code results available to callers and files accessible through SDK or CLI operations. It fits teams that need an isolation layer for temporary or untrusted workloads while retaining local Docker and Kubernetes deployment options.
Applications call Sandbox.create to provision a sandbox and sandbox.commands.run to execute shell commands; the resulting execution object exposes logs. They can write files with sandbox.files.write_files and retrieve them with sandbox.files.read_file. CodeInterpreter.create(sandbox) attaches a code interpreter to an existing sandbox, and interpreter.codes.run executes code in a specified language and returns results and logs. The osb CLI initializes connection settings, creates sandboxes, runs commands, moves files, inspects diagnostics, and manages runtime egress policy. opensandbox-mcp exposes sandbox creation, command execution, and text-file operations to MCP-capable clients.
- A developer-platform team needs short-lived isolated environments for a code-execution service on Docker or Kubernetes.
- A coding-agent team wants to run Claude Code, Gemini CLI, OpenAI Codex CLI, Qwen Code, or Kimi CLI inside a sandbox.
- A test-automation engineer needs isolated Chromium, Playwright, VNC, or code-server environments for browser and desktop tasks.
- An evaluation team needs one sandbox per trial when running a Harbor agent evaluation.
- An application developer using LangGraph or Google ADK needs a workflow that writes files, reads files, and executes commands.
How do you install or deploy this agent?
Local execution requires Docker and Python 3.10+. Run:
uvx opensandbox-server init-config ~/.sandbox.toml --example docker
uvx opensandbox-serverInstall the CLI:
pip install opensandbox-cliThen initialize and configure the connection:
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>For MCP, install and start:
pip install opensandbox-mcp
opensandbox-mcp --domain localhost:8080 --protocol httpHow do you use this agent?
After configuration, create and invoke a sandbox:
osb sandbox create --image python:3.12 --timeout 30m -o json
osb command run <sandbox-id> -o raw -- python -c "print(1 + 1)"With the Python SDK, create an instance through await Sandbox.create(...), then call await sandbox.commands.run(...), sandbox.files.write_files(...), and sandbox.files.read_file(...) inside async with sandbox. For code execution, first create interpreter = await CodeInterpreter.create(sandbox), then call await interpreter.codes.run(..., language=SupportedLanguage.PYTHON).
What are this agent's strengths and limitations?
- It offers Python, Java/Kotlin, JavaScript/TypeScript, C#/.NET, and Go SDKs alongside CLI and MCP access paths.
- Docker supports local execution, while the Kubernetes runtime targets distributed scheduling.
- Commands, files, and code interpretation have concrete interfaces, with examples for browsers, desktops, coding CLIs, evaluation, and training.
- Its network features include a unified ingress gateway, per-sandbox egress control, and Credential Vault injection for outbound requests.
- The documentation names gVisor, Kata Containers, and Firecracker microVM as supported options for stronger isolation.
- Local execution explicitly depends on Docker and Python 3.10+; Kubernetes adoption requires the corresponding runtime environment and deployment setup.
- The CLI example requires connection.domain, connection.protocol, and an API key, but the supplied material does not explain API-key issuance or server authentication setup.
- Secure container runtimes are listed as supported, but their configuration, performance, and feature tradeoffs need validation in the target environment.
- The breadth of SDKs, MCP, ingress, egress, and credential injection means teams must select and operate the component set they actually need.
How does this agent compare with similar options?
Key facts side by side with the most closely related agents.
| Agent | Source review | Form / cost | Stars | Updated | Language | Full support on |
|---|---|---|---|---|---|---|
| OpenSandbox Runtime This agent | 47 · Major gaps | Library / SDKFree | ★ 16k | today | Python | Codex · Claude Code |
| Stakpak | 57 · Major gaps | CLIFree + model costs | ★ 1.9k | 4mo ago | Rust | OpenAI API · Claude API |
| SandBase Harness | 52 · Major gaps | CLIFree + model costs | ★ 640 | 1d ago | TypeScript | OpenAI API · Claude API |
| OptimNow Cloud FinOps Library | 65 · Some gaps | Agent plugin / skillFree | ★ 66 | 1d ago | Python | Claude Code |
How does FollowAgents rate this agent?
Why each dimension lost points
Evidence shows emphasis on least privilege (network policies, secure container runtimes) but lacks implementation details; user confirmation mechanism not explicit; data flow transparency limited; sensitive data handling has credential vault but details insufficient; dependency security has security policy but no dependency list; external effects have network policies but default behavior not stated; rollback not mentioned; source attribution has release signatures but unverified.
Self-consistency good, docs align with code structure; dependency availability lacks full dependency list; failure messages have CLI tests but not all scenarios.
Audience and scenarios clear (coding agents, browser automation); capability boundaries documented; trigger precision not explicit; environment fit supports Docker and Kubernetes.
Information architecture clear with project structure table; install notes detailed; naming stability not explicit; examples abundant; known limitations not explicit; license Apache-2.0; versioning/changelog not provided; maintenance responsibility not explicit.
Output usability has CLI and SDK examples; marginal value high with multiple integrations; cost-benefit lacks performance data.
Claim traceability limited, some features documented but not verified; cross-source corroboration insufficient; fact-inference separation unclear.
- Publisher identity unverified, proceed with caution.
- Dependency security lacks full dependency list, audit needed.
- User confirmation mechanism not explicit, may affect approval workflows.
- Rollback mechanism not mentioned, needs confirmation.
Recent releases
Latest entries from the project's GitHub Releases. Notes are quoted from upstream as written, not rewritten or tested by FollowAgents.
-
Release notes excerpt
First release candidate on the 1.2.1 patch line, cut from release-1.2.0 (2026-10-27). Headline: OSEP-0025 Credential Vault Exchange — an exchange credential source with per-request header resolution through a pluggable resolver, wired end to end across egress, server, all five SDKs, fast-sandbox e2e, and the Credential Vault guide. Also notable: execd atomic uploads, digest validation for rootfs snapshots, Kubernetes create-timeout startup diagnostics, and informer-cache scoping for large clusters. Baseline for every section is release-1.2.0. rc releases publish images but hold package …View on GitHub ↗ -
release-1.2.0 OpenSandbox 1.2.0
Release notes excerpt
Stable cut of the 1.2.0 line, carrying everything merged since release-1.1.1 through two release candidates plus a post-rc hardening delta. Images shipped with the rcs; SDK/CLI/server packages publish at 1.2.0. Everyone on 1.1.x should upgrade. Baseline for every section below: release-1.1.1. Highlights …View on GitHub ↗ -
release-1.2.0-rc.2 OpenSandbox 1.2.0-rc.2
Release notes excerpt
Second release candidate on the 1.2.0 line, carrying everything merged since release-1.2.0-rc.1 — the headline is the Credential Vault (OSEP-0022) landing end to end for fast sandboxes: an egress-held vault with durable per-subject persistence and pause/resume transfer, the user-reachable server-routed vault API, and a pool-pinned MITM CA. Network policy follows the same egress-held pattern, and NetworkRule gains port-scoped rules in the classic profile — fast sandboxes reject them fail-closed until the fastlet nft path enforces them. Images publish now; SDK/CLI packages ship at the `1.2 …View on GitHub ↗