TLDR: OpenSandbox is now an Agentic AI Foundation project. It is an open source agent isolation platform for AI applications, providing unified APIs for running agentic workloads in a safe manner. It includes SDKs for multiple languages and supports Docker and Kubernetes runtimes. OpenSandbox is licensed under Apache 2.0 and available today at open-sandbox.ai.
A coding agent needs an isolated environment where it can use its tools. For example, the agent may need to clone a repository and install dependencies. It may then edit files, run tests, start a development server, and inspect the results.
Running those operations on the host machine could give the agent access to files and services outside the task. In a sandbox, the agent has an isolated environment with limited access to the host machine.
But that introduces another problem: how should the agent create that environment, interact with it, and eventually tear it down?
Many sandbox providers have their own APIs for creation, storage, networking, security, and deletion. An agent built directly against one of those implementations becomes tightly coupled to it.
OpenSandbox takes a different approach. It treats the sandbox as a reusable primitive with a common set of APIs, while leaving the underlying runtime free to implement those APIs differently.
A common contract for sandboxes
At the center of OpenSandbox is its sandbox protocol, a set of OpenAPI specifications that define the public contracts applications use to work with sandbox environments.
The protocol has two main parts:
- Agents use our lifecycle API to create, inspect, pause, resume, renew, take a snapshot of, and delete a sandbox.
- Agents use our execution API to run commands and code, work with files, open sessions, and collect resource measurements inside the sandbox.
Through the common interface, an agent can request a sandbox with a specific configuration instead of creating a Docker container or Kubernetes workload itself. The request is converted into instructions for the configured runtime.
OpenSandbox currently includes runtime backends for Docker and Kubernetes that connect the common OpenSandbox interface to a specific system.
The same lifecycle interface is used with both backends. The Docker backend creates and manages a container directly, and the Kubernetes backend creates a workload and its related resources.
OpenSandbox provides a runtime-neutral API, while each runtime handles execution in its own way. Docker and Kubernetes remain different systems, but agents can use the same operations for the parts they share
Following an agent task through OpenSandbox
Suppose a coding agent needs to clone a repository and run its tests. The agent, or the application coordinating it, first requests a sandbox through an OpenSandbox SDK.
The OpenSandbox lifecycle server validates the request and hands the provisioning work to the configured runtime service.
Agent → OpenSandbox SDK → Lifecycle API → Runtime
The runtime service then creates a Docker container or Kubernetes workload from the request, and a sandbox is created in the background.
Sandbox creation is asynchronous. Once the environment reaches its running state, the agent has an isolated place to work.
But creating the sandbox is only half the problem. The agent still needs a way to operate inside it.
Inside the sandbox
An execution daemon named execd runs inside each sandbox and handles requests to perform work there.
The agent uses execd to:
- run shell commands and code
- read, create, change, and delete files and directories
- keep shell sessions open between commands
- collect measurements about CPU, memory, and other resources
To clone a repository, for example, the agent sends a git clone command through the SDK. The command is passed to execd and runs inside the sandbox. The agent uses the same path to install dependencies, change files, and run tests.
The complete task follows these steps:
- The agent requests a sandbox through the lifecycle API.
- The configured runtime creates the sandbox.
- The agent sends commands and file operations to
execd. - Results and resource measurements are returned to the agent.
- The sandbox is deleted when the work is complete or its expiration time is reached.
From the agent's perspective, those interactions use the same OpenSandbox interfaces whether the sandbox is backed by Docker or Kubernetes.
Why agents need a common sandbox interface
Sandboxing itself is not new. Containers and virtual machines have been isolating workloads for years. What’s changing is who needs to create and control them.
In agent systems, the sandbox is something software requests while a task is running. An infrastructure team doesn’t have to provision each environment ahead of time.
If every agent framework and evaluation platform develops its own contract for provisioning and controlling execution environments, developers rebuild the same abstraction.
OpenSandbox treats the sandbox as a common primitive. The runtime and infrastructure can change without requiring changes to the agent.In those systems, the sandbox is no longer something an infrastructure team provisions ahead of time. It becomes something software asks for dynamically.
That makes the interface to the sandbox increasingly important.
If every agent framework, coding agent, evaluation platform, and AI application develops its own contract for provisioning and controlling execution environments, developers end up rebuilding the same abstraction repeatedly.
OpenSandbox is proposing that the sandbox itself can become a common primitive.
The runtime underneath it can change. The infrastructure can change. The workload can change.
The agent shouldn’t have to.
That is the bet behind OpenSandbox.
Get involved
- Read the documentation.
- Read the architecture overview.
- Contribute to OpenSandbox on GitHub.
- Join the community on Discord.
Share
Author
