How to Run Claude Code or Codex Safely in a Docker Sandbox

The safest practical default for running Claude Code or Codex unattended is a microVM sandbox with a private repository clone, deny-by-default network access, and host-side credential injection. With Docker Sandboxes, that means launching the agent with --clone, keeping shared skills disabled for untrusted work, allowing only the domains the task needs, and reviewing the sandbox branch before anything reaches your host checkout.

A sandbox is a boundary, not a verdict. Docker's default direct-mount mode still lets the agent change your host working tree. Use clone mode when the repository or task is unfamiliar, and treat every file the agent produces as untrusted until you review it.

What You Are Isolating

Docker Sandboxes runs each coding agent in a microVM with its own Linux kernel, Docker Engine, filesystem, and network. HTTP and HTTPS traffic passes through a host-side proxy. Raw TCP, UDP, ICMP, private networks, loopback, and link-local addresses are blocked by default.

The important exception is the workspace. In direct mode, the project is mounted read-write, so changes appear on the host immediately. That includes Git hooks, CI workflows, IDE tasks, package scripts, and agent configuration that another trusted host process might execute later.

Pillar Security described this trust handoff in July 2026: several agent sandbox bypasses did not require breaking the sandbox kernel. The agent only needed to write a file that a trusted host component later loaded or ran. Docker's --clone mode closes much of that path by keeping the writable clone inside the microVM and mounting the host repository read-only.

Prerequisites

You need:

1. macOS, Windows, or Ubuntu supported by the current Docker Sandboxes release.

2. A Git repository with committed or safely stashed host changes.

3. A Docker account for sbx login.

4. An Anthropic or OpenAI account for the selected agent.

5. A list of the exact external domains the task needs.

Before starting, confirm that the host repository is clean:

git status --short

Expected result: no output. If you see unrelated tracked changes, stop. Commit, stash, or move them intentionally before giving an agent access.

Step 1: Install the sbx CLI

On macOS with Homebrew:

brew trust docker/tap
brew install docker/tap/sbx
sbx login

On Ubuntu, use Docker's current repository installer and KVM setup:

curl -fsSL https://get.docker.com | sudo REPO_ONLY=1 sh
sudo apt-get install docker-sbx
sudo usermod -aG kvm "$USER"
newgrp kvm
sbx login

Then verify the installation:

sbx version
sbx diagnose

Expected result: sbx version prints a version and sbx diagnose reports the daemon, storage, authentication, and virtualization checks as passing or gives a specific remediation.

Step 2: Store the Model Credential on the Host

Do not paste provider API keys into the sandbox shell. Docker Sandboxes can keep the real value in the host keychain and inject it into matching outbound requests through the proxy.

For Claude Code with an Anthropic API key:

sbx secret set -g anthropic

For Codex with host-side OAuth:

sbx secret set -g openai --oauth

You can also let sbx run codex start the host authentication flow or use /login inside Claude Code for a subscription login. Docker documents that Codex OAuth runs on the host and that the token does not enter the sandbox.

Expected result: the agent authenticates without a raw provider key appearing in the sandbox environment.

Step 3: Start in Clone Mode

For Claude Code:

sbx run --clone --no-share-skills --name project-claude \
  claude ~/path/to/project

For Codex:

sbx run --clone --no-share-skills --name project-codex \
  codex ~/path/to/project

Expected result: the agent opens against a private clone inside the microVM. Your host working tree and host .git directory remain unchanged.

The --no-share-skills flag matters for untrusted work. Supported agents otherwise mount a persistent shared skills store read-write, which creates a path for one sandbox to influence later sessions.

Docker currently launches Codex inside this microVM with --dangerously-bypass-approvals-and-sandbox. That flag disables Codex's inner command sandbox because Docker's microVM and policy become the outer enforcement boundary. It does not make the host boundary optional. Clone mode, network policy, credential isolation, and review are what make that configuration defensible.

Step 4: Check the Effective Network Policy

Inspect the active rules before asking the agent to install packages or call APIs:

sbx policy ls --wide
sbx policy check network api.anthropic.com
sbx policy check network api.openai.com
sbx policy check network github.com

Expected result: the selected model endpoint is allowed, while unrelated destinations are denied unless you added a narrow rule.

If the task needs a package registry, add only the required domains. For example:

sbx policy allow network "registry.npmjs.org,*.npmjs.org"
sbx policy log

Avoid sbx policy allow network "**". It converts deny-by-default egress into broad internet access and weakens the protection against data exfiltration. If organization governance is active, organization policy replaces local rules; sbx policy ls shows which source is effective.

For a reproducible negative-control matrix, see How to Test AI Agent Sandbox Network Isolation.

Step 5: Keep External Actions Behind a Credential Broker

The model credential is not the only secret at risk. GitHub, Slack, database, billing, and deployment credentials should not be copied into the VM either.

Aident Loadout lets an agent discover an Action, inspect its schema, preflight cost and risk, and execute through a connected Vault without receiving the provider credential.

Start with read-only checks:

aident account auth status
aident vault vault --action status
aident capabilities search \
  --queries '["GitHub list repository issues"]' \
  --types '["action"]' \
  --limit 5

Copy the exact canonical Action name from search, then inspect and preflight it before execution:

aident capabilities get --name '<canonical-action-name>'
aident capabilities preflight \
  --name '<canonical-action-name>' \
  --input '<narrow-read-only-input>'

Expected result: the schema requests task inputs, not a raw provider secret, and preflight identifies the operation and any cost or approval requirement. If the schema requests a secret or an unbounded destination, do not execute it.

For the underlying pattern, read How to Give AI Agents API Access Without Exposing Keys.

Step 6: Review the Sandbox Output Before Trusting It

Clone mode exposes the sandbox repository through a local Git remote named for the sandbox. On the host, find and fetch it:

git remote -v | rg '^sandbox-project-claude'
git fetch sandbox-project-claude
git branch -r | rg 'sandbox-project-claude/'

Substitute the returned branch name in the review commands:

git diff --stat origin/main...sandbox-project-claude/<branch>
git diff --name-status origin/main...sandbox-project-claude/<branch>
git diff origin/main...sandbox-project-claude/<branch>

Expected result: only task-relevant files changed. Review executable configuration, hooks, dependency scripts, and agent settings with extra care. Fetching is not approval; merge or check out the branch only after review and tests.

This is the key defense against delayed trust-handoff attacks. The microVM contains the running process, while the explicit Git review controls what later reaches host tools.

Common Failure Modes

Do not reset sandbox state as a first troubleshooting step. Start with sbx diagnose, sbx policy log, and a daemon restart. A reset deletes sandbox data.

Why This Setup Works

The microVM separates kernels and processes. Clone mode separates writable Git state. Deny-by-default egress limits where data can leave. Host-side credential injection keeps model secrets out of the VM. A credential broker keeps provider secrets behind narrow, auditable Actions. The final host-side diff review prevents sandbox-written files from silently becoming trusted inputs.

No single layer is enough. Together, they turn an unattended coding agent from a process with ambient host authority into a constrained worker whose code and external effects cross explicit review points.

Ready to verify the external boundary? Set up Aident and preflight one read-only Action, then confirm that no provider key appears in the sandbox and that the preflight names the exact operation.

Sources

• Docker Sandboxes, Docker, accessed August 1, 2026

• Security model, Docker, accessed August 1, 2026

• Isolation layers, Docker, accessed August 1, 2026

• Default security posture, Docker, accessed August 1, 2026

• Credentials, Docker, accessed August 1, 2026

• Local policy, Docker, accessed August 1, 2026

• Claude Code in Docker Sandboxes, Docker, accessed August 1, 2026

• Codex in Docker Sandboxes, Docker, accessed August 1, 2026

• Docker Sandboxes release notes, Docker, July 10, 2026

• Sandboxing, Anthropic, accessed August 1, 2026

• The Week of Sandbox Escapes, Pillar Security, July 20, 2026