Docker · Sandboxing · AI Agents

Docker Sandboxes — o básico

Container era pouco. Voltamos pras VMs — só que pequenas, descartáveis e com um Docker dentro.

Docker lançou o sbx em março de 2026: uma CLI que cria sandboxes isolados pra rodar agentes de IA. A surpresa é que cada sandbox não é um container — é uma microVM com kernel próprio e um daemon Docker inteiro lá dentro. A história está fechando o ciclo: depois de uma década empurrando container, a Docker volta pras VMs.

TL;DR sbx roda agentes de IA em microVMs com kernel, filesystem e Docker daemon próprios. O agente pode rm -rf /, instalar o que quiser e rodar docker build — sem chegar perto do seu host. Isolamento de hardware com cold start quase instantâneo.

O que é

Docker Sandboxes é a resposta da Docker pra um problema que ficou óbvio com a chegada dos agentes de programação: você quer dar liberdade pro Claude Code, Gemini CLI ou Codex executarem comandos arbitrários, mas não no seu laptop.

A CLI chama sbx (de sandbox). Roda à parte do Docker Desktop e é instalada separadamente. Cada vez que você dá sbx run claude, uma microVM nova sobe em segundos, com:

Kernel Linux próprio
Filesystem próprio
Stack de rede próprio
Daemon Docker próprio rodando lá dentro

O agente vive nesse universo paralelo. Quando termina (ou enlouquece), você joga a VM fora e sobe outra. Custo: alguns segundos.

Por que microVM, e não só container

Container compartilha kernel com o host. Pra agente de IA, isso traz dois problemas difíceis ao mesmo tempo:

Agente quer rodar Docker. Um agente que faz desenvolvimento real precisa de docker build, docker compose up, etc. Isso significa Docker-in-Docker, que historicamente exige privilégios elevados (--privileged) — e aí o sandbox já era.
Escape de container é mais fácil do que de VM. Bug de kernel compartilhado = todo mundo do mesmo host na mesma piscina.

Resolver isso com VM tradicional resolveria o isolamento — mas VMs demoram pra subir, e desenvolvedor que espera 30 segundos pulariu o sandbox. A aposta da Docker foi construir o próprio VMM (Virtual Machine Monitor) usando o hypervisor nativo de cada OS, otimizado pra cold start:

OS	Hypervisor usado
macOS	Hypervisor.framework (Apple)
Windows	Windows Hypervisor Platform
Linux	KVM

Eles poderiam ter usado Firecracker (o microVM da AWS Lambda), mas Firecracker é Linux-only. A Docker queria que o mesmo comando funcionasse no MacBook do dev, no Windows da empresa e no Linux da CI — daí o VMM próprio.

O ciclo fechou. VMs → containers (2013, Docker) → microVMs (2018, Firecracker, infra-only) → microVMs no desktop (2026, Docker sbx). Cada camada resolveu uma dor da anterior. Agentes autônomos trouxeram a dor de volta.

Como funciona por baixo

Cada sbx run sobe uma microVM completa. Container roda dentro do daemon Docker da VM, não no daemon do host.

A diferença prática: o agente dentro da VM #1 não enxerga a VM #2, não enxerga o host, não enxerga seus arquivos pessoais. Pra ele, o universo é o filesystem daquela VM. Pra compartilhar código com o agente, você monta um workspace explicitamente — nada vaza por padrão.

Instalar

O sbx é uma CLI separada do Docker Desktop. Cada plataforma tem seu canal:

macOS · Apple Silicon

brew install docker/tap/sbx
sbx login

Windows · x86_64

winget install -h Docker.sbx
sbx login

Linux · Ubuntu

curl -fsSL https://get.docker.com | sudo REPO_ONLY=1 sh
sudo apt-get install docker-sbx
sbx login

Em Windows, o Windows Hypervisor Platform precisa estar habilitado. Em Mac, só Apple Silicon (M1+). Em Linux, KVM disponível.

Comandos do dia a dia

subir agente

# sobe uma microVM nova com o Claude Code dentro
sbx run claude

# mesma coisa, mas amarrando a sandbox a um branch dedicado
sbx run claude --branch my-feature

# generic shell, sem agente
sbx run shell

gerenciar

sbx ls              # listar sandboxes ativas
sbx stop my-sandbox # parar
sbx rm  my-sandbox  # remover

credenciais (ficam no host, injetadas na VM)

sbx secret set -g anthropic
sbx secret set -g github -t "$(gh auth token)"

rede (default: nega tudo)

sbx policy ls
sbx policy allow network registry.npmjs.org

Sem argumento nenhum (sbx), abre um dashboard interativo no terminal — lista sandboxes, status, permite attach, abrir shell, ajustar regras de rede.

Quando usar

O caso óbvio é o que motivou a feature:

Rodar agentes de IA com permissão liberal. Em vez de aprovar cada comando que o Claude Code quer executar, você libera tudo dentro da sandbox e esquece. Se ele estragar algo, é a VM que paga.
Testar instalações duvidosas. Aquele script de curl | sh que você não quer rodar no host.
Build environments descartáveis. Compilar projeto antigo que pede dependências exóticas, sem poluir seu sistema.
Reprodução de bugs. Estado limpo, mesmo kernel, mesmo Docker, todas as vezes.

Onde não faz sentido: workload de produção (não é pra isso), processos sensíveis a latência de I/O (microVM tem overhead, ainda que pequeno), uso casual de container (continua sendo docker run mesmo).

Onde fica nesse ecossistema: Firecracker (AWS) é microVM pra provider rodar funções de cliente. sbx é microVM pra desenvolvedor rodar agente no laptop. Mesmo princípio, público diferente.

Pra onde aprofundar

Esse foi o panorama. A partir daqui dá pra ir fundo em vários ângulos — internals do VMM da Docker, comparação detalhada com Firecracker e gVisor, network policies em produção, integração com Claude Code especificamente, ou o custo real de cold start medido. Me diga onde quer cavar.

Fontes: docs.docker.com/ai/sandboxes · get-started · why microVMs (blog)