Sandboxes for agents reach general availability
Cloudflare has announced that its Sandboxes product, along with the underlying Cloudflare Containers platform, is now generally available. The service was built around a straightforward premise: AI agents that act like developers need somewhere safe to do developer things — cloning repositories, building code in multiple languages, running dev servers — and stitching together VMs or container solutions for that purpose creates a long list of hard problems.
Those problems include burstiness (spinning up many sandboxes quickly without paying for idle standby), fast state restoration between sessions, secure service access without handing credentials to agents, programmatic control of the sandbox lifecycle, and a simple interface that humans and agents can both use. Cloudflare says it has spent the time since its June preview solving those issues, with partners like Figma already running agents in containers for its Figma Make product.
A sandbox you can name and resume
A Cloudflare Sandbox is a persistent, isolated environment powered by Cloudflare Containers. You request a sandbox by name: if it's already running, you get it; if not, it starts. The sandbox sleeps automatically when idle and wakes on request. Programmatic interaction uses methods like exec, gitClone, and writeFile. Because requests are routed by ID, the same sandbox can be reached from anywhere in the world.
Credentials stay out of the agent's hands
Authentication is one of the hardest parts of agentic workloads. Agents often need to reach private services, but trusting them with raw credentials is a non-starter. Sandboxes address this with credential injection at the network layer via a programmable egress proxy. The agent never has access to the credentials themselves, and the authentication logic is fully customizable. The model supports identity-aware credential injection, dynamically modifiable rules, and integration with Workers bindings.
A real terminal over WebSocket
Early agent systems treated shell access as a request-response loop: run a command, wait for output, feed the transcript back into the prompt. That works, but it isn't how developers actually use a terminal — where you watch output stream in, interrupt, reconnect later, and keep going.
PTY support shipped in February gives Sandboxes a pseudo-terminal session proxied over WebSocket and compatible with xterm.js. Calling sandbox.terminal serves the backend; an xterm addon connects from the client. Each terminal session gets its own isolated shell, working directory, and environment, and you can open as many as needed. Output is buffered server side, so reconnecting replays anything you missed.
A code interpreter that holds state
Sandboxes also ship a persistent code execution context for data analysis, scripting, and exploratory work. Unlike many interpreter implementations that run each snippet in isolation and lose state between calls, these contexts keep variables and imports alive across calls — the same way a Jupyter notebook does.
Servers, URLs, and live feedback
To let agents build something and show it immediately, Sandboxes support background processes, readiness checks, and preview URLs. An agent can start a dev server and share a live link without leaving the conversation. The waitForPort() and waitForLog() abstractions let agents sequence work on real signals from the running program instead of guessing with sleep(2000) calls.
Filesystem watching, shipped in March, improves iteration speed for agents making changes. sandbox.watch() returns an SSE stream backed by native Linux inotify events, letting an agent observe the filesystem in real time and participate in the same event-driven feedback loops as a human developer — save a file, rerun the build; edit a config, restart the server.
Snapshots for fast session recovery
A human developer can clone a repo, run npm install, write code, push a PR, and close the laptop — then resume exactly where they left off after the review comes back. Replicating that on a naive container platform is awkward: either keep the sandbox running and pay for idle compute, or start fresh from the image and wait through git clone and npm install again.
Snapshots, rolling out in the coming weeks, preserve a container's full disk state: OS config, installed dependencies, modified files, and data. They can be configured to trigger automatically when a sandbox sleeps, or taken programmatically for checkpointing or forking work — for instance, booting four sandboxes from the same state to run agent instances in parallel. Snapshots are stored in R2 within the account, and R2's tiered caching enables fast restores across all of Region: Earth.
Future releases will also capture live memory state, so running processes can resume exactly where they left off — a terminal and editor reopening in their prior state. For those who need session restoration before snapshots go live, the existing backup and restore methods persist and restore directories using R2; they are not as performant as true VM-level snapshots but still offer significant speed improvements over recreating session state from scratch. The difference is notable: booting a sandbox, cloning the axios repository, and running npm install takes about 30 seconds, while restoring from a backup takes roughly two.
