Docker announced Cloud Sandboxes on September 24, introducing cloud-hosted microVM environments that let coding agents such as Claude Code, Codex, and Copilot run tasks in isolation even after a developer disconnects their laptop. The release targets long-running agent workflows by combining local control with managed cloud execution while preserving network, secret, and filesystem policies. Engineers now gain a consistent path to move agent sessions between on-device and remote setups without losing state or security boundaries.

Docker launched Cloud Sandboxes on September 24 to address a growing friction point in AI-assisted development. Coding agents often begin tasks on a laptop and then need hours or days to complete code generation, testing, or refactoring. When the local machine sleeps or loses connectivity, those sessions break. The new offering places each agent inside a lightweight microVM that continues execution in Docker’s managed cloud, returning results or updated files once the developer reconnects.

Technical foundation of the microVMs

Each Cloud Sandbox runs on a minimal virtual machine rather than a shared container. Docker uses a Firecracker-derived hypervisor to boot a stripped-down Linux kernel in milliseconds. The microVM receives a private network namespace, a mounted filesystem snapshot, and an encrypted secrets store passed from the user’s local Docker Desktop or CLI. Because the environment is virtualized at the hardware boundary, an agent inside the sandbox cannot access host resources or other sandboxes even if its code contains vulnerabilities.

Developers define sandbox policies through familiar Docker Compose syntax extended with a new sandbox top-level key. A typical configuration specifies allowed egress domains, which environment variables become secrets, and whether the agent may open listening sockets. These policies travel with the workload when it migrates to the cloud, so the same rules apply whether the agent runs locally or remotely.

Integration with popular coding agents

Claude Code, OpenAI Codex, and GitHub Copilot already support remote execution modes. Docker’s release adds first-class connectors for each. When an agent is launched with the --cloud flag, the CLI packages the current workspace, policy file, and agent credentials into an OCI image, pushes the image to Docker’s registry, and starts the microVM. The agent receives a stable IP address and can continue calling external APIs or internal services according to the declared policy.

State persistence works through a copy-on-write filesystem layer. Changes made by the agent are stored in a snapshot that survives VM restarts. When the developer returns, the snapshot can be pulled back into a local volume or inspected through a web dashboard. This design eliminates the need to commit partial work simply to keep an agent alive.

Why the timing matters

Agent-driven coding has moved from experimental demos to daily practice inside many engineering organizations. Teams report that a single complex refactoring task can consume tens of minutes of agent runtime. Laptops are not designed to stay awake for that duration, and corporate VPNs often drop idle connections. Cloud Sandboxes remove the requirement to keep a personal machine online while still giving engineers full visibility and control over what the agent may access.

Security teams have welcomed the explicit policy layer. Previously, agents running on developer laptops inherited the full corporate network trust of that laptop. With Cloud Sandboxes, access is scoped to only the domains and secrets listed in the compose file. Audit logs record every outbound connection and file write performed inside the microVM.

Reactions from practitioners

Early users note that the migration between local and cloud feels seamless once the initial policy file is written. One engineer described starting a multi-hour test-generation run at the end of the workday and reviewing the diff the next morning without leaving any processes on the laptop. Another highlighted the ability to hand an agent task to a colleague by sharing the sandbox identifier rather than the entire workspace.

Platform engineers are examining how the feature fits into existing CI/CD pipelines. Because sandboxes expose a standard Docker API surface, existing build tools can target them without modification. Some teams are already scripting nightly agent runs that produce pull requests while developers are offline.

Implications for DevOps and security workflows

The release extends Docker’s historical role from local container tooling into managed cloud primitives. Organizations that already standardize on Docker images gain a path to run untrusted agent code without provisioning separate Kubernetes clusters or serverless functions. Network policies defined once apply uniformly, reducing the chance of configuration drift between environments.

Cost models are still being finalized, but Docker has indicated that billing will be based on vCPU-seconds and storage consumed by snapshots. This usage-based approach aligns with how many teams already pay for agent API calls, allowing finance teams to attribute spend directly to specific coding tasks.

Looking ahead

Docker plans to expose additional controls in the coming months, including GPU-backed microVMs for agents that perform local model inference and deeper integration with identity providers for secret rotation. The company is also working with agent vendors to surface sandbox identifiers inside their respective UIs so developers can launch a cloud session without touching the CLI.

Whether Cloud Sandboxes become the default runtime for long-running agents will depend on pricing transparency and the breadth of supported agent frameworks. For now, the September 24 release gives engineering teams a concrete way to keep agent work moving without sacrificing isolation or control.