Docker Gives Coding Agents Their Own Kernel—What Happens to Your Files?

Docker wants you to give a coding agent its own computer. In a November 5 explanation, the company draws a distinction that matters whenever an agent can run shell commands: a standard container shares its host’s kernel; Docker Sandboxes give the agent a microVM with its own Linux kernel and Docker Engine. That changes where the agent’s operating environment ends. It does not make every file you hand it disposable. Docker’s architecture comparison

As of November 7, the practical buying question is less glamorous than agent intelligence: which resources should an autonomous process be allowed to touch? Docker’s answer includes free local sandbox compute, paid cloud compute and separate paid organization controls. Builders need to evaluate those layers separately before treating a sandbox as permission to walk away.

A container packages an app; an agent operates a machine

A web service usually starts with a defined executable and a reasonably predictable job. A coding agent gets an objective and starts improvising: inspect a repository, fetch dependencies, change configuration, launch a database, rebuild an image. The environment has to accommodate that activity without casually handing over the developer’s workstation.

Docker’s November 5 post describes Sandboxes as dedicated microVMs with their own kernel, filesystem, network and Docker Engine. The private Engine matters for agents doing application development: they can work with containers inside their own environment. Docker recommends keeping containers for application workloads while putting the agent operating those workloads in a sandbox. Docker’s comparison

Consider an agent repairing a service that depends on PostgreSQL and Redis. It may need to start dependencies, inspect logs and rebuild repeatedly. The useful evaluation is whether the isolated environment supports that entire loop. A boundary that forces you to grant broader host access halfway through the task has failed the workflow, even if the initial demo looked tidy.

This is an architectural distinction, not a published productivity result. The cited comparison does not establish how much faster your migration will finish or how many defects an agent will prevent. Builders should judge the product on the permissions it removes from a real assignment, then measure whether the assignment still succeeds.

Your project remains something the agent can damage

Isolation protects resources outside the boundary. Resources deliberately exposed inside it still need a plan. If the assignment requires editing your application, the agent needs access to application files. A microVM cannot decide that a particular deletion was a terrible interpretation of your request.

Start an evaluation with a disposable checkout and a clean commit. Give the agent a bounded change, such as replacing one deprecated library call across a package. Inspect the resulting diff and run the project’s relevant checks before accepting the work. These are recommendations for evaluating the workflow, rather than claims about automatic Docker protections.

Treat output recovery as a separate requirement from containment. Can you identify the files that changed? Can you recover the starting state? Can you retrieve the result if the session ends? Those questions expose a surprisingly common mistake: designing an excellent place for an agent to work without designing how its work gets home.

Docker’s documentation explicitly distinguishes local and cloud operation. Cloud sandboxes cannot mount a host workspace or use host hardware, and the two environments have separate credentials, network policies and lifecycle controls. A workflow that works locally therefore needs a fresh review before moving remotely. Cloud sandbox documentation

Free local compute does not mean a free agent

Docker says the sbx CLI and local sandbox compute are free, including for commercial work. Cloud compute uses a pay-as-you-go subscription, while model-provider charges remain separate. Centrally managed organization policies require another paid subscription. Those are distinct spending decisions, even when the developer sees one terminal session. Docker Sandboxes overview

For a local pilot, the direct cost question is therefore mostly your existing machine capacity and agent-provider bill. For a remote pilot, add the runtime infrastructure charge. For a team deployment, ask whether you also need centrally enforced rules rather than relying on each developer to configure an environment correctly.

Do not substitute the Docker Desktop prices visible in website navigation for a Cloud Sandboxes quote. The documentation identifies cloud access and governance as separate subscriptions. A familiar company logo is a poor billing specification. Record exactly which subscription, compute usage and provider account a proposed deployment consumes.

The sensible unit to measure is cost per accepted change. Track the sandbox’s active duration, the agent’s usage bill and the review needed to produce something mergeable. A cheap run that leaves an unusable patch is still wasted spend. Conversely, paying for remote compute may make sense if it lets a useful job finish without occupying a developer’s machine. Neither outcome follows from the word “sandbox.”

The cloud handoff has operational differences

Docker introduced Cloud Sandboxes on September 24, pitching a way to keep agent work running away from a laptop and move environments between local and managed compute. That addresses an ordinary problem: a long task should not depend on whether someone closes a lid or leaves a desk. Docker’s cloud announcement

The current cloud guide supplies the details the pitch leaves out. It requires sbx version 0.45.0 or later and an active Docker Agentic Platform subscription. The documented connectivity check is sbx --cloud diagnose. Local agent credentials are not automatically available remotely; cloud credentials must be configured separately. Cloud setup guide

Most consequentially, the guide says cloud sandboxes expire after one hour by default. On expiration, the service stops environments that can be resumed and deletes the rest. Docker tells users to check the timeout action before depending on retained work. An overnight assignment therefore needs an explicit lifecycle decision before you disconnect.

For an initial remote trial, choose a small repository and an output you can verify independently. Retrieve the patch or report before removing the environment. Docker documents copying results back and warns that removal deletes files stored only inside the sandbox. Build that retrieval step into the assignment rather than remembering it after the session disappears.

An account is part of the operating boundary

Docker requires sign-in and explains it as a way to associate sandboxes with a verified identity, authenticate infrastructure access and support team features. Its FAQ also says the CLI collects command usage telemetry, including success or failure, duration and the Docker username when signed in. It says that telemetry excludes prompts and code. Docker FAQ

That telemetry statement should not be confused with a claim that cloud execution keeps source files on your laptop. The same FAQ explicitly says transferred files are stored on Docker-managed infrastructure. For a private repository, remote execution is a decision about where code may reside as well as where CPU time is purchased.

For organizations, the FAQ describes centrally managed network, filesystem and MCP policies for local sandboxes. With organization governance active, organization allow rules grant access; local allow rules no longer do, while local deny rules still apply. Cloud network controls use separate configuration. That distinction deserves a place in rollout documentation, especially for teams using both environments.

Before a pilot, write down the package registries, Git hosts and external tools the assignment needs. Also identify credentials that should never enter the environment. Then check the configuration against that list. This is more useful than asking whether the product is “safe” without specifying what it must be able to reach.

Evaluate the boundary with one real assignment

A useful pilot has three observable outcomes: the agent completes a representative task, the environment exposes only the resources needed for it, and the team can recover and review the result. Choose work that exercises your development loop. A documentation edit will tell you little about a workflow that normally builds images and starts databases.

Record each point where the agent needs an exception. Perhaps it requires another registry, a missing tool or a credential with narrower scope. Those interruptions are evidence about the environment you need to provide. Resist fixing them by granting broad access simply to get the demonstration over with.

Also separate containment from correctness. An agent can remain neatly inside its allotted machine while producing a bad migration, weakening validation or misunderstanding a requirement. Review the patch against the assignment and run meaningful checks. The operating boundary and the acceptance decision solve different problems.

Docker’s proposition is concrete: give autonomous coding work a more complete machine boundary, with local and managed options. The payoff for builders is the opportunity to grant useful capabilities without granting the whole workstation. Whether that works for your repository depends on what you expose, what you retain and what you review.

Frequently asked questions

Is Docker Sandboxes free for commercial work?

Yes. Docker says the CLI and local sandbox compute are free for commercial use. Cloud compute, provider usage and organization governance are separate costs.

Can a cloud sandbox mount my laptop’s project folder?

No. Docker’s cloud guide says host workspace mounts are unavailable. Transfer files or clone a repository inside the remote environment.

Can I leave the default cloud sandbox running overnight?

Check its expiration settings first. The documented default is one hour, with expiration either stopping a resumable sandbox or deleting it.