Run AI coding agents in Docker Sandboxes with controlled workspace and tool access

An AI agent needs enough access to install dependencies and inspect a failing application. Giving it a production SSH key, an entire home directory and unrestricted administration tools turns that debugging task into a much larger grant of authority.

AI coding agents in Docker Sandboxes work in a separate environment while you decide what to share. The guide scopes an AI agent sandbox, shows how to run Claude Code in Docker Sandboxes as a named experiment, reviews credentials and MCP, and checks generated work.

AI coding agents in Docker Sandboxes can work inside a separate execution environment while you decide which resources are shared. The useful question is not simply whether a sandbox exists. It is whether its workspace, network, credentials and integrations match the specific task.

This guide follows Docker's current local sbx workflow, reviewed on 11 October 2026. Older tutorials may use a different command family. Recheck the installed release and official installation guide before copying commands.

Our prompt injection guide explains why retrieved instructions remain untrusted even inside an isolated runtime.

Step 1: Write a small task contract

Define the repository, the intended change and the acceptance evidence. A useful first task is diagnosing a build failure in a sanitized sample application. Production database repair is a poor first experiment.

For example, the agent may inspect source, install locked development dependencies and propose a patch. It may not publish packages, alter production configuration or deploy anything. Keep those constraints enforced by available permissions and credentials, not just prompt wording.

Record an owner, maximum runtime and provider spending budget. Choose a stop condition for repeated installation failures. This prevents an unsuccessful loop from continually consuming paid API calls while widening access.

Step 2: Confirm the supported local runtime

Docker documents local Sandboxes as microVM-based execution with a separate Docker environment. The agent can have broad privileges inside that VM without receiving automatic access to the host Docker daemon.

Check the installation page for the exact platform requirements. Linux local execution requires supported virtualization, and a machine already running inside a VM may require nested virtualization. Do not assume an arbitrary VPS or an Ubuntu derivative is supported.

Keep the host daemon socket out of the task. A socket bridge would grant a separate form of host authority that is unnecessary for building containers inside the isolated environment.

Step 3: Select workspace access deliberately

Use a separate sanitized repository as the starting point. Exclude production environment files, customer exports and private keys. A read-only mount still permits reading; it is not a secret redaction mechanism.

Current clone mode requires a Git repository and has constraints around secondary Git worktrees. It follows the checked-out ref without creating a new branch automatically. Verify these conditions before building an automation script around it.

Step 4: Create a named, scoped experiment

The following example assumes the supported sbx CLI is installed, the chosen agent is configured and the current directory is the sanitized main Git checkout. The domain is a fictional production destination to replace with the actual prohibited endpoint.

sbx create --clone --name devops-review \
  --deny-network prod.example.com claude .
sbx policy ls devops-review --wide
sbx policy ls devops-review --source kit --type network --wide
sbx run --name devops-review

Inspect the policy before attaching. A deny for one hostname is only one restriction; other routes, credentials and integrations still need review. Avoid resetting a global policy as a troubleshooting shortcut on a machine with other active tasks.

A network preset can include baseline allowances, while an agent kit can add its own rules. Inspect the effective named-sandbox policy. A preset name alone is insufficient evidence that only the intended destinations are reachable.

Step 5: Review credentials and MCP separately

Use the supported credential mechanism rather than placing API keys in agent-readable environment files. Docker describes proxy-based injection for supported credentials; that protection does not remove the authority to use the permitted provider or incur costs.

Review every MCP server connected through the host gateway. A local server can execute on the host rather than inside the microVM. A tool called inspect deployment may still have write credentials behind it.

Disable unnecessary integrations. Prefer bounded read-only tools for investigation, with independent permissions for production mutations. Our MCP security guide covers server trust and action approval in more detail.

Also examine forwarded SSH access and shared agent skills. A forwarded signing capability can be powerful even when private key bytes are not copied. Shared writable instructions can affect later sessions, so treat their contents and mount permissions as part of the review.

Step 6: Review generated work before trusted execution

Inspect the complete diff, including lockfiles, build scripts, hooks and CI configuration. A small application fix can hide a broad change to release permissions or a new network download during installation.

Execute acceptance checks in an isolated target environment using synthetic data. Verify the original failure and a representative success case. Record which commands were actually run and which remain proposed.

Step 7: Preserve work and retire the experiment

Stopping a sandbox and removing it are different operations. Keep useful patches, diagnostic notes and permitted artifacts before removal. Do not treat a saved runtime template as a complete repository backup.

If a session exposed a credential or invoked an unintended integration, stop the session, revoke that authority and inspect relevant audit records. Recreating the VM alone does not undo external actions.

For help introducing controlled AI-assisted development into an existing release process, discuss your workflow with Cloudsoft Zone. Start with one observable task and expand access only when its operating evidence justifies the change.

Featured image: Cloudsoft Zone technical layout with docker artwork by dotCloud, Inc. (Apache License 2.0). Product mark resized proportionally for identification; no endorsement implied. Layout: CC BY-SA 4.0.