Cloud sandboxes solve where agents run, not how well they reason

The compute problem for long-running coding agents is largely solved now. Docker's cloud sandboxes address the obvious gap: a laptop sleeps, throttles on battery, and drops connections. Agents that run for hours need always-on compute with consistent network access. microVMs, metered by the second, with a one-command handoff from local to cloud—this is sensible infrastructure, and the pricing makes it cheap enough to experiment with freely.

But solving the compute problem doesn't solve the trust problem, and that's the part worth thinking harder about.

Isolation is not the same as oversight

Docker's isolation model—each agent in its own microVM with configurable network policies—protects your machine from the agent. That's valuable. A rogue tool call can't touch your filesystem or leak credentials to an unexpected endpoint. Per the published summary, network access is configurable per agent, which is the right design.

What a sandbox can't do is protect your task from a confused agent. An agent that misunderstands the scope of a refactor at hour one will still be misunderstanding it at hour eight. The microVM will be intact. Your codebase may not be.

This is the real trade-off with long-horizon agents: the longer you let them run unmonitored, the more an early wrong turn compounds. A thirty-minute task with a bad first step produces a bad output. A ten-hour task with the same bad first step produces something harder to untangle.

What we'd actually do

The right response isn't to avoid long-running agents. It's to design them with explicit checkpoints before you hand off to cloud compute.

Before moving a sandbox from local to cloud—Docker's sbx move command makes this a single step—define what "done" means at each major stage, not just at the end. Use the agent's output at hour two as a deliberate review point, not a morning surprise. The infrastructure is durable enough to pause; your workflow should be designed to use that.

Network policies also deserve more thought than they usually get at setup time. An agent that can reach any external endpoint is an agent that can exfiltrate context, even from inside a microVM. Docker's per-agent network policies make precision practical here. The default should be an allowlist, not an open network with a few blocked endpoints.

The bigger shift

Docker is right that development is changing: developers will direct more and type less. But "reviewing what comes back in the morning" only works if you trust both the environment and the agent's judgment. Docker has made meaningful progress on the environment side. The judgment side—better mid-task checkpointing, structured intermediate output, tighter task scoping—is still mostly an open problem that lives above the infrastructure layer.

Cloud sandboxes are good infrastructure for a workflow you still have to design carefully. The sandbox keeps the agent in bounds. You still have to keep the task in scope.

Sources

• Introducing Cloud Sandboxes: Start on Your Laptop, Finish in the Cloud | Docker (original)
• Found via the TLDR newsletter