Bonus: What Docker Sandboxes Was Actually Built For

Table of Contents

1. Same tool, different job
2. Run an agent in a sandbox
3. What the agent can and can't touch
4. Cleaning up
5. Shell mode vs agent mode: when to use which
6. Beginner Pitfalls

1. Same tool, different job

Parts 1–8 used sbx run shell to turn Docker Sandboxes into a disposable Docker learning environment. That's a legitimate, documented use — but it's not the use case Docker actually built this product for. The real pitch: give an autonomous AI coding agent a full Linux environment with its own Docker daemon, so it can install packages, run tests, and build containers while it works — without ever touching your host beyond the one project directory you choose to share.

Everything you learned about sbx run, sbx ls, sbx ports, sbx stop, and sbx rm carries over unchanged. Only the first argument to sbx run changes.

2. Run an agent in a sandbox

Pick a real project directory (not ~/sbx-crash-course — this is a separate sandbox) and start an agent instead of a plain shell. sbx run supports several built-in agents: claude, codex, copilot, cursor, devin, docker-agent, droid, gemini, kiro, opencode — we'll use Claude Code as the example:

cd ~/some-real-project
sbx run --name my-agent-sandbox claude

Same network-policy prompt as before on first run — Balanced is still a sensible default. If you have a Claude subscription (Max, Team, or Enterprise), authenticate right inside the sandbox with /login; no upfront API key setup needed. The session token stays on your host and is never stored inside the sandbox itself.

You're now attached to Claude Code, running inside the sandbox, with a full Linux environment and its own Docker daemon at its disposal — the same capabilities you had in shell mode, just driven by the agent instead of you typing commands.

3. What the agent can and can't touch

From another terminal, on your host:

sbx ls

SANDBOX             AGENT    STATUS    PORTS   WORKSPACE
my-agent-sandbox     claude   running           ~/some-real-project

• The workspace column is the one directory the agent can see and edit — your project. Changes it makes appear in your working tree immediately, reviewable as an ordinary Git diff before you commit anything.
• Everything else — packages it installs, containers it starts, files outside the workspace — stays inside the sandbox's own disk, invisible to your host, and deleted along with the sandbox.
• Network access is governed by the same policy you already know: sbx policy ls to inspect it, sbx policy allow network <host> to widen it.

If you'd rather the agent not touch your working tree directly at all — useful when running several agents against one repository in parallel — --clone gives it a private, in-sandbox Git clone instead:

sbx run --clone claude ~/some-real-project

4. Cleaning up

Exactly the same commands as the rest of this course:

sbx stop my-agent-sandbox
sbx rm my-agent-sandbox

sbx rm deletes everything the agent installed or built inside the sandbox. Your project directory on the host is untouched either way.

5. Shell mode vs agent mode: when to use which

Same CLI, same isolation guarantees, two very different jobs. Reach for shell when you want a disposable Linux box for yourself; reach for an agent name when you want to hand real work to something autonomous without giving it the keys to your machine.

6. Beginner Pitfalls

• Don't reuse sbx-crash-course for this — it doesn't have a real project in it, and mixing an agent session into your learning sandbox makes it harder to reason about later. A fresh, purpose-named sandbox is cheap.
• The agent's workspace is exactly the directory you ran sbx run from (or passed explicitly) — not your whole home directory, and not other projects on your machine.

That's the core course. The next four parts go into the deeper end of Docker Sandboxes that's specifically about agents: packaging setup into reusable kits, declaring a whole project's sandbox in an environment file, giving agents safe tool access through the MCP gateway, and running several agents at once.