O que Docker Sandboxes realmente é

Para gerenciar lançamentos, você pode baixar um binário direto da página releases da Docker no GitHub.

sbx-releases

Primeiro, vamos esclarecer o que esta ferramenta é e o que não é.

  • Não é um contêiner. Sim, ela usa o nome Docker e contém contêineres dentro dela. Mas cada sessão de sandbox roda dentro da sua própria microVM, com seu próprio kernel. Isso é isolamento real de nível de hardware, como uma máquina virtual completa, e não o tipo mais leve de isolamento que contêineres normais usam.
  • Não precisa do Docker Desktop. Ela vem com sua própria ferramenta de linha de comando, chamada sbx. Você pode usá-la em uma máquina que nunca teve Docker Desktop instalado.
  • Cada sandbox recebe seu próprio daemon Docker privado. É isso que a diferencia de outras ferramentas de sandboxing para agentes. Seu agente pode executar docker build, docker run e docker compose totalmente dentro do sandbox, sem precisar compartilhar a instalação Docker do host.
  • O limite de isolamento é o hipervisor, não apenas um processo. Se um agente se comportar mal ou for comprometido, ele ainda não alcança seus arquivos do host, o daemon Docker do host, outros sandboxes ou sua rede. Ele só alcança o que você permitir explicitamente.

Agentes de IA de codificação como Claude Code, GitHub Copilot CLI, Codex, Gemini e Cursor agora podem run comandos, editar arquivos e instalar pacotes sozinhos, sem pedir confirmação a todo momento. O Claude Code inclusive tem a flag --dangerously-skip-permissions para isso. Isso os torna rápidos, mas também arriscados: um agente que pode run rm -rf, ler suas chaves secretas ou quebrar um serviço é seguro apenas até o limite do espaço em que roda. Se você executa um agente direto no laptop, ele pode tocar tudo o que sua conta de usuário pode tocar.

O ponto da Docker é simples: um modelo de IA não deveria decidir os próprios limites de segurança. Essa decisão precisa vir do sistema ao redor, não do modelo sendo solícito. Por isso, a equipe da Docker introduziu o Docker Sandboxes.

Para funcionar em todas as plataformas, a Docker construiu seu próprio Virtual Machine Monitor (VMM). Não reutilizou o Firecracker, porque o Firecracker só funciona no Linux com KVM. Em vez disso, o VMM da Docker roda nativamente usando:

  • macOS: Hypervisor.framework
  • Windows: Windows Hypervisor Platform (HypervisorPlatform)
  • Linux: KVM

É por isso que os sandboxes iniciam quase instantaneamente, mesmo usando isolamento de nível de VM. Normalmente, VMs são bem mais lentas para iniciar do que contêineres, mas a Docker contornou esse problema.

Como é construído (Arquitetura)

Estes são os fatos principais sobre como o Docker Sandboxes funciona, conforme a documentação de segurança da própria Docker:

  • Sua pasta de projeto é a única ponte padrão para o host. Por padrão, o Docker Sandboxes compartilha sua pasta de projeto com o sandbox em modo leitura-gravação. Essa é a única parte da sua máquina que o agente pode ver. Todo o resto — outros arquivos, o daemon Docker do host e sua rede — permanece completamente fora do sandbox.
  • O tráfego de rede passa por um proxy. O proxy verifica cada requisição de saída contra uma lista de permitir/negar. Ele também injeta credenciais, como seu token do GitHub ou a chave de API do modelo, nessa camada. O processo do agente pode nunca ver seus segredos reais; ele só pode usá-los contra destinos aprovados.
  • Tudo dentro de um sandbox pode ser descartado. Pacotes instalados, imagens baixadas, contêineres em execução e histórico do shell vivem no próprio sistema de arquivos do sandbox. Quando você remove o sandbox, tudo isso desaparece. O host permanece intocado.

Aviso: O Docker Sandboxes é novo. A Docker mostrou a ferramenta em dezembro de 2025 e a lançou em março de 2026. O software muda rápido. A versão estável atual no momento desta escrita é v0.38.0 (lançada em agosto de 2026). Alguns recursos, como "kits" personalizados, ainda estão marcados como Early Access. Comandos podem mudar. Sempre execute sbx version para verificar o que você tem e consulte também a documentação oficial.

Instalando Docker Sandboxes no Linux, macOS e Windows

O que você precisa, por plataforma

  • Linux: kernel com suporte a KVM habilitado, usuário no grupo kvm e, se estiver rodando dentro de uma VM ou ambiente VDI, virtualização aninhada ativada.
  • macOS: o Virtualization.framework da Apple, já disponível no sistema.
  • Windows: Windows Hypervisor Platform (WHP) ativado.

Em todos os casos, o login na conta Docker é obrigatório.

Linux: Verifique se o KVM está disponível

Antes de tentar qualquer outra coisa, verifique se o módulo KVM está habilitado:

lsmod | grep kvm

Você deve ver kvm_intel, kvm_amd ou kvm na saída:

kvm_intel             552960  0
kvm                  1527808  1 kvm_intel
irqbypass              16384  1 kvm

Se não vir nada, execute kvm-ok para descobrir o motivo. Sem KVM, sbx não inicia. Você também precisa adicionar seu usuário ao grupo kvm:

sudo usermod -aG kvm $USER

Depois, faça logout e login novamente, ou execute newgrp kvm, para que a mudança tenha efeito.

Importante: se você estiver executando esta configuração dentro de uma VM ou ambiente VDI, é preciso ativar a virtualização aninhada. O Docker Sandboxes é, ele mesmo, uma ferramenta de hipervisor; a VM externa precisa permitir virtualização dentro dela.

Windows: Ative o hipervisor primeiro

Abra o PowerShell como administrador e execute:

Enable-WindowsOptionalFeature -Online -FeatureName HypervisorPlatform -All

Comandos de instalação

Linux (Ubuntu):

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

macOS:

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

Windows:

winget install -h Docker.sbx
sbx login

Executar sbx login imprime a seguinte mensagem no terminal:

Your one-time device confirmation code is: XXXX-XXXX
Open this URL to sign in: https://login.docker.com/activate?user_code=XXXX-XXXX
By logging in, you agree to our Subscription Service Agreement. For more details, see https://www.docker.com/legal/docker-subscription-service-agreement/
Waiting for authentication...

Abra o navegador, cole a URL fornecida e complete o processo de login da Docker. Clique em Configurar para registrar seu dispositivo.

O login na conta Docker é obrigatório, não opcional. Se você não tiver acesso a um gerenciador de pacotes, também pode baixar um binário direto da página releases da Docker no GitHub. Se quiser os builds mais recentes antes de um lançamento estável, pode instalar um build noturno, por exemplo brew install docker/tap/sbx@nightly.

Verifique a versão do sandbox e mantenha-o atualizado

$ sbx version
sbx version: v0.38.0 c022b14634c4bea846ca12870d1d5e97d5868b54

Para atualizar:

# Linux (Ubuntu)
sudo apt-get update && sudo apt-get install --only-upgrade docker-sbx
# macOS
brew upgrade docker/tap/sbx
# Windows
winget upgrade Docker.sbx

Quando você atualiza no Windows ou via Homebrew, o processo reinicia automaticamente o daemon em segundo plano (sandboxd) para você. Não é preciso fazer esse passo manualmente.

Algumas dicas específicas para Windows

  • Depois de winget install, o arquivo sbx.exe pode acabar em %LOCALAPPDATA%\DockerSandboxes\bin\, e o PATH pode não atualizar imediatamente. Se sbx não for encontrado logo após a instalação, faça logout e login novamente, ou abra uma nova janela de terminal.
  • Se você acabou de ativar HypervisorPlatform, reinicie a máquina antes de executar sbx create pela primeira vez. Pular a reinicialização costuma causar travamento ou um erro confuso de hipervisor, em vez de uma mensagem clara pedindo a reinicialização.
  • sbx armazena seu login e inicia o daemon dentro da sua sessão normal de desktop. Configurar tudo via SSH, sem um desktop interativo, não funciona bem no Windows.

Seu Primeiro Sandbox, Passo a Passo

Entre com seu agente

Se você usa Claude Code com uma assinatura Claude (Max, Team ou Enterprise), não há configuração extra. Basta executar /login dentro do sandbox na primeira vez; o login acontece pelo navegador. A equipe da Docker afirma que o token de login permanece na máquina host e nunca é armazenado dentro do sandbox.

Se preferir usar uma chave de API, salve-a com sbx secret set. Para permitir que o agente abra pull requests ou faça outras operações no GitHub:

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

Inicie seu primeiro sandbox

cd ~/my-project
sbx run --name my-sandbox claude

Na primeira execução, sbx pede que você escolha uma política de rede padrão:

Initialize the global network policy for your sandboxes:
1. Open         — All network traffic allowed, no restrictions.
❯  2. Balanced     — Default deny, with common dev sites allowed.
2. Locked Down  — All network traffic blocked unless you allow it.

Se você está começando, escolha Balanced. Ela permite tráfego comum de desenvolvimento, como registro npm, PyPI e GitHub, e bloqueia todo o resto por padrão. Você pode mudar isso depois.

Você pode trocar claude por qualquer outro agente. No momento, o Docker Sandboxes suporta Claude Code, Codex, GitHub Copilot CLI, Cursor, Droid, Gemini, Kiro, OpenCode, o próprio Docker Agent e um modo Shell sem agente.

Na primeira vez, o sandbox demora um pouco mais para iniciar porque a Docker baixa a imagem base do agente. Depois, a mesma imagem é reutilizada, e os lançamentos seguintes começam em poucos segundos.

Veja o que o sandbox pode tocar

Abra um segundo terminal e execute:

$ sbx ls
SANDBOX       AGENT    STATUS    PORTS   WORKSPACE
my-sandbox    claude   running           ~/my-project

A coluna WORKSPACE mostra a única coisa que o sandbox e sua máquina compartilham. Quando o agente altera um arquivo ali, você vê a mudança na pasta de trabalho imediatamente e pode revisá-la com um git diff normal, como faria com uma mudança feita por um colega humano.

Verifique e ajuste o que ele pode alcançar online

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

Se você escolher Locked Down, até a API do próprio modelo fica bloqueada até que você a permita. É uma boa configuração para repositórios com dados sensíveis.

Limpe quando terminar

sbx stop my-sandbox     # pause it; everything stays saved
sbx rm my-sandbox        # delete it for good; packages and images go away too

Um sandbox permanece salvo entre stop e resume. Pacotes instalados, imagens Docker baixadas e histórico do shell sobrevivem a uma pausa. Mas rm exclui tudo dentro do sandbox, inclusive qualquer clone git interno se você usou o modo clone. Sua pasta de projeto real no host nunca é tocada por rm.

Comandos principais do sbx (Referência rápida)

Estes são os comandos sbx que você usará com mais frequência:

$ sbx run claude                         # start or reconnect to an agent
$ sbx ls                                 # list your sandboxes and their status
$ sbx stop <name>                        # pause a sandbox
$ sbx rm <name>                          # delete a sandbox for good
$ sbx rm --force <name>                  # force-delete, even mid-session
$ sbx exec -it <name> bash               # open a shell inside a running sandbox
$ sbx cp ./file.json <name>:/home/user/  # copy a file from host to sandbox
$ sbx cp <name>:/home/user/out.log ./    # copy a file from sandbox to host
$ sbx ports <name> --publish 8080:3000   # forward a port for a running sandbox
$ sbx daemon restart                     # restart the background daemon
$ sbx                                     # open the interactive dashboard

Todo comando sbx fala com o daemon em segundo plano sandboxd. Se um sandbox começar a se comportar de forma estranha depois de uma mudança de configuração, como uma configuração de proxy, tente sbx daemon restart antes de excluir qualquer coisa.

Nota de segurança sobre sbx cp: Copiar arquivos para fora de um sandbox (do sandbox para o host) foi alvo de um bug de segurança real e público, identificado como CVE-2026-17106 e apelidado de "CopyEscape". Antes de confiar em sbx cp para puxar arquivos de um sandbox que você não conhece totalmente, certifique-se de estar executando sbx versão 0.38.0 ou posterior.

Se sbx disser que a "política de rede padrão não foi configurada", defina uma você mesmo:

sbx policy set-default <allow-all|balanced|deny-all>

Atenção: o comando usa palavras diferentes do menu exibido na primeira execução. A correspondência é: Open → allow-all, Balanced → balanced, Lockdown → deny-all.

Reconectando a um sandbox e nomeando-o

Se você executar sbx run duas vezes na mesma pasta, ele apenas reconecta você ao mesmo sandbox, em vez de criar um novo:

sbx run claude ~/my-project   # creates the sandbox
sbx run claude ~/my-project   # reconnects to it

Se você der um nome ao sandbox, pode reconectar de qualquer pasta:

sbx run claude --name my-project
sbx run --name my-project        # reconnect later, from any folder

Também é possível executar vários agentes no mesmo repositório, desde que cada um tenha seu próprio nome:

sbx run claude --name feature ~/my-project
sbx run claude --name spike   ~/my-project

Criando um sandbox sem abri-lo imediatamente

sbx create --name my-project claude .
sbx run --name my-project        # attach whenever you're ready

Duas maneiras de trabalhar com git

Existem duas formas bem diferentes de um agente tocar seu repositório.

  • Modo direto (o padrão): o agente tem acesso total de leitura-gravação à sua pasta de trabalho real. As mudanças aparecem no host imediatamente.
  • Modo clone (--clone): o agente trabalha em um clone git separado dentro do sandbox. Nada toca sua pasta de trabalho real até que você mesmo faça fetch ou o agente faça push. O repositório do host fica visível dentro do sandbox, mas somente leitura.
sbx run --clone claude

O modo clone é uma boa escolha quando você executa vários agentes no mesmo repositório e não quer que eles pisem nas mudanças uns dos outros. Também é útil se você ainda não confia o suficiente em um agente para deixá-lo editar sua pasta de trabalho diretamente.

Alguns detalhes sobre o modo clone:

  • Ele é definido na criação do sandbox. Não dá para ativá-lo depois; seria preciso excluir o sandbox e criar outro.
  • O clone segue o branch que o repositório do host tem checkout no momento da criação. Ele não cria um branch novo.
  • Só funciona com um repositório git real. Também não funciona a partir de uma árvore de trabalho git não principal, porque o mount somente leitura não consegue seguir o arquivo de ponteiros .git da árvore de trabalho.
  • Se você remover um sandbox em modo clone, o clone interno também desaparece. Portanto, faça fetch ou push de qualquer coisa importante antes.

Compartilhando mais de uma pasta

Você pode montar mais de uma pasta do host em um sandbox:

sbx run claude ~/project-a ~/shared-libs:ro ~/docs:ro

O primeiro caminho listado se torna o espaço de trabalho principal, e é o que o modo clone usa. Qualquer coisa listada depois é apenas um mount extra. Adicione :ro para tornar uma pasta somente leitura.

Abrindo uma porta de dentro do sandbox

Os sandboxes são isolados na rede nas duas direções. Suas ferramentas do host não alcançam um servidor de desenvolvimento rodando dentro de um sandbox, a menos que você publique a porta, como faria com um contêiner Docker normal:

sbx run --publish 8080:3000 --name my-sandbox claude

Para um sandbox que já está rodando:

sbx ports my-sandbox --publish 8080:3000

No navegador, abra http://localhost:8080.

Se você publicar apenas a porta do lado do sandbox, o sistema escolhe uma porta livre no host. Você pode consultá-la com:

sbx ports my-sandbox --publish 3000
sbx ports my-sandbox

O Painel Interativo

Se você digitar apenas sbx, sem argumentos, ele abre um painel de tela cheia no terminal.

Cada sandbox aparece como um cartão ao vivo, com status, CPU e memória. Pelo painel você pode:

  • criar um sandbox com c
  • pausar ou retomar com s
  • anexar a um sandbox com Enter
  • abrir um shell com x
  • remover um sandbox com r

Há também um painel de rede, aberto com tab, onde você observa conexões de saída em tempo real e altera as regras de permitir/negar. Pressione ? a qualquer momento para ver a lista completa de atalhos.

Para quem está começando, esse é o jeito mais fácil de explorar a ferramenta, sem precisar memorizar todos os comandos.

Credenciais e Segredos

O Docker Sandboxes tenta manter segredos brutos fora do sandbox, para que um agente comprometido não consiga roubá-los. Existem duas formas de dar acesso a um segredo.

Serviços integrados são tratados por um proxy no host, então o agente nunca lê o segredo diretamente:

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

Outras variáveis de ambiente, como BRAVE_API_KEY ou um token interno da empresa, não têm serviço integrado. Nesse caso, você precisa escrevê-las diretamente no arquivo de ambiente persistente do sandbox:

sbx exec -d <sandbox-name> bash -c "echo 'export BRAVE_API_KEY=your_key' >> /etc/sandbox-persistent.sh"

Isso significa que o processo do agente pode ler essas variáveis, diferentemente dos segredos baseados em proxy. Use esse método apenas quando a opção de proxy não estiver disponível.

O arquivo carrega automaticamente toda vez que um shell inicia dentro do sandbox, então o valor permanece durante toda a vida do sandbox. Observe a parte bash -c. Por padrão, sbx exec <name> <command> executa o comando sem um shell; por isso, >> e o arquivo de ambiente não funcionam a menos que o comando seja envolvido dessa forma.

Em Linux headless, quando não há um chaveiro de desktop rodando, sbx recorre automaticamente a um arquivo criptografado armazenado em ~/.config/com.docker.sandboxes, com permissões restritas. Isso é mais fraco que um chaveiro real do sistema operacional, mas ainda funciona, e o sbx informa claramente quando está usando esse fallback.

Por que você deve entrar

Ao contrário de um comando docker run simples, você não pode usar sbx sem uma conta. O login com sbx login é obrigatório. Os motivos, segundo a equipe da Docker:

  • Cada sandbox recebe uma identidade verificada. Isso importa porque um agente autônomo pode construir contêineres, instalar pacotes e enviar código em seu nome; é preciso haver um registro claro de responsabilidade.
  • Recursos de equipe, como governança para toda a organização, ambientes compartilhados e logs de auditoria, dependem de um conceito de "quem" desde o início.
  • Os sandboxes também precisam autenticar com os servidores da Docker para puxar imagens e executar daemons.

A equipe da Docker afirma que o email da conta é usado apenas para login, nunca para marketing. O CLI coleta uma pequena quantidade de dados de uso: qual comando foi executado, se funcionou, quanto tempo levou e seu nome de usuário, se você estiver conectado. Ele explicitamente não coleta seus prompts nem seu código. Para desativar isso completamente:

export SBX_NO_TELEMETRY=1

O que é grátis e o que custa dinheiro

  • Grátis, inclusive para uso comercial, sem taxa por assento: o CLI sbx e tudo o que este guia cobriu até aqui.
  • Pago, com uma assinatura separada: governança organizacional, com políticas de rede, sistema de arquivos e MCP gerenciadas centralmente, exigência de login e entrega de logs de auditoria.

Em resumo: um desenvolvedor pode usar o modelo completo de isolamento e segurança gratuitamente. Você só paga se quiser aplicar políticas centralmente em uma empresa inteira.

Os agentes ainda custam dinheiro

O Docker Sandboxes dá a você uma caixa gratuita para rodar um agente, mas o agente em si é um produto separado, de outra empresa, e geralmente não é grátis.

O Claude Code precisa de uma assinatura Claude (Pro, Max, Team ou Enterprise) ou cobrança de API via Anthropic. O GitHub Copilot CLI precisa de uma assinatura Copilot. Codex, Gemini, Cursor e os demais agentes suportados têm seus próprios preços.

Ou seja: você continua pagando pelo agente escolhido, exatamente como pagaria se rodasse direto no desktop ou laptop, sem sandbox. O sandbox não adicion um custo, e também não remove um.

Por que os agentes pulam prompts de aprovação (e como trazê-los de volta)

Esta é provavelmente a maior mudança de mentalidade para quem está começando com a ferramenta.

Normalmente, executar um agente com uma flag como o --dangerously-skip-permissions do Claude Code é genuinamente arriscado em uma máquina comum. É exatamente por isso que a flag tem "perigosamente" no nome.

Mas o argumento da Docker é diferente quando você está dentro de um sandbox. Nesse caso, o próprio sandbox se torna o limite de segurança. As razões usuais para prompts de aprovação — impedir comandos destrutivos, bloquear acesso à rede ou capturar mudanças de arquivos não revisadas — já são tratadas pelo limite da VM, pela política de rede e pelo isolamento de credenciais.

Se você quiser os prompts de aprovação de volta em uma sessão, a maioria dos agentes permite alternar modos no meio da sessão. No Claude Code, digite /permissions.

Para tornar o modo cauteloso o padrão em todas as sessões, você pode criar um kit personalizado que remove a flag de pular permissões do comando de inicialização do agente:

# claude-safe/spec.yaml
schemaVersion: "1"
kind: sandbox
name: claude-safe
sandbox:
image: "docker/sandbox-templates:claude-code-docker"
entrypoint:
run: [claude]

sbx run claude-safe --kit ./claude-safe/

Tenha em mente que kits e templates ainda são marcados como Early Access na documentação da Docker, e o formato já mudou uma vez.

A partir de v0.38.0, novos kits usam por padrão o esquema v2, que reorganiza os campos em blocos mais claros, como permissions.network.allow/deny e setup.install, substituindo o estilo mais antigo e achatado, como network.allowedDomains e commands.install.

Kits v1 mais antigos ainda carregam por um caminho legado, mas o carregador é estrito quanto a misturar os dois formatos: um spec v2 com campos v1 restantes falha em vez de funcionar silenciosamente. Portanto, execute sbx kit validate ./your-kit antes de distribuir um kit, e consulte a referência de kit atual para a lista completa de campos. Kits podem ser distribuídos como pasta local, arquivos ZIP, artefatos OCI ou URLs Git.

Outros recursos experimentais que vale a pena conhecer

A partir de v0.38.0, três recursos estão atrás de flags experimentais. Trate-os como genuinamente experimentais:

  • Passagem de GPU (somente Linux): sbx run --gpu permite que um sandbox use passagem de GPU NVIDIA VFIO. Primeiro, ative com sbx settings set feature.sandbox-gpu true.
  • Modelos locais: sbx run --model <name> claude executa o Claude Code contra um modelo GGUF local, em vez de uma API hospedada. Adicione o prefixo ollama/ para puxar um modelo de uma instalação Ollama existente.
  • Rede empresarial: você pode configurar proxies upstream separados para tráfego de sandbox e de daemon, além de login de proxy NTLM/Kerberos no Windows.

Pensando em modelos locais para cortar custos?

Ir para o local remove assinaturas e taxas de API, mas não é automaticamente "grátis" no geral. Você ainda precisa de uma GPU com memória suficiente para rodar um modelo capaz a uma velocidade utilizável; comprar uma pode custar mais do que anos de assinatura hospedada, se você ainda não tiver uma.

Modelos locais de peso aberto também ainda tendem a ficar atrás de modelos hospedados como o Claude no tipo de trabalho de codificação autônomo de várias etapas que este guia cobre, embora essa lacuna continue diminuindo.

E note que sbx run --model ainda roda dentro do ambiente do Claude Code; ele apenas troca qual modelo alimenta o agente. É útil para testes locais ou para manter o código fora de uma API externa.

O Gateway MCP (Novo na v0.38.0)

A partir de v0.38.0, o sbx adicionou suporte adequado para gerenciar servidores Model Context Protocol (MCP).

Isso é diferente de configurar um servidor MCP diretamente dentro de um agente, como a configuração MCP do próprio Claude Code. O gateway resolve um problema distinto: você registra um servidor uma vez no host e pode reutilizá-lo em todos os sandboxes e agentes, sem nunca colocar as credenciais dentro do sandbox.

sbx mcp add notion --url https://mcp.notion.com/mcp
sbx mcp add playwright --command npx --args @playwright/mcp@latest
sbx mcp ls
sbx mcp inspect notion

Se um servidor remoto precisar de OAuth, sbx mcp add executa o fluxo de login uma vez, no registro, e armazena o token no armazenamento de credenciais do host. Depois, o gateway anexa o token às requisições de saída do sandbox, mas o token nunca entra na VM.

Ao criar um sandbox, você escolhe um de dois modos de conexão:

  • Modo estático (--static-mcp server1,server2) pré-carrega uma lista fixa e esconde as ferramentas de descoberta do agente. É a opção mais restrita e segura.
  • Modo dinâmico (o padrão) permite que o agente descubra e conecte-se a servidores registrados por conta própria, no meio da sessão, usando as ferramentas integradas mcp-find e mcp-add.

Nota importante: servidores MCP locais baseados em stdio rodam no seu host, fora da proteção do sandbox, com as permissões do seu usuário. A equipe da Docker recomenda registrar apenas comandos e imagens testados dessa forma. Servidores remotos baseados em HTTP não têm esse problema, porque o gateway faz o proxy deles.

Problemas de segurança conhecidos e por que você deve manter-se atualizado

Leia esta seção com atenção antes de confiar em um sandbox com qualquer coisa sensível.

O Docker Sandboxes ainda é um software jovem. Como ele lida com código não confiável por design, já teve bugs de segurança reais e publicamente divulgados. Dois deles foram lacunas no isolamento de rede. O mais recente, porém, foi uma fuga para o sistema de arquivos do host pelo recurso de -copy de arquivos.

A conclusão é: a lista de permissões de rede não cria um limite perfeito por si só. Ela só funciona tão bem quanto o lançamento atual, e cada lançamento precisa fechar todos os possíveis canais laterais, como DNS ou ICMP, um de cada vez.

O caminho de cópia de arquivos entre host e sandbox também tem sido um alvo real. Se você roda sandboxes com credenciais ou dados sensíveis, trate o número da versão como uma questão de segurança ativa, não apenas um detalhe de instalação -t:

sbx version

Verifique sua versão contra as notas de lançamento ou a página releases, e atualize usando os comandos da seção de instalação se estiver desatualizado.

No momento da escrita, versão 0.38.0 ou posterior inclui correções para todos os três bugs mencionados. Como o CVE-2026-17106 é recente, seja especialmente cuidadoso com a direção de cópia de sbx cp até confirmar que está na 0.38.0 ou posterior. Quando possível, prefira revisar mudanças por git diff em um espaço de trabalho compartilhado de leitura-gravação, em vez de copiar arquivos arbitrariamente para fora de um sandbox que você ainda não confia totalmente.

Nada disso significa que você deva desconfiar do design geral. Isolamento de nível de VM para arquivos e processos é uma abordagem genuinamente sólida, e a Docker tem enviado correções rapidamente. Os dois bugs de junho de 2026 foram corrigidos em cerca de duas semanas após o relato, e a correção do CopyEscape foi lançada no mesmo lançamento em que o bug foi divulgado.

Não instale uma vez e esqueça. Verifique a versão regularmente, especialmente antes de usar sbx cp para puxar arquivos de um sandbox não confiável, ou antes de confiar na lista de permissões de rede como uma parede perfeita.

Algumas dicas práticas que valem a pena conhecer

  • sbx run ignora --publish na reconexão. Se você está reanexando a um sandbox existente e precisa de uma nova porta encaminhada, use sbx ports <name> --publish ... em vez disso. A flag --publish em run só funciona na criação do sandbox.
  • Sandboxes não copiam todas as configurações do agente da sua conta de usuário. Hooks e configurações em pastas como ~/.claude permanecem no host. Apenas a configuração de nível de projeto dentro da pasta de trabalho é compartilhada. A exceção é o compartilhamento de habilidades do agente, que você ativa com sbx skills import. Além disso, não confie em symlinks apontando para caminhos do host: um agente em sandbox não consegue segui-los para fora da própria VM.
  • A colagem de imagens da área de transferência é desativada por padrão, porque ativá-la permite que um processo em sandbox leia a área de transferência do host pelo proxy. Você pode ativá-la com sbx settings set clipboard.imagePaste true.
  • Não tem certeza se está em sandbox? Pergunte ao agente. No Claude Code, use /btw are you running in a sandbox?. É uma verificação rápida antes de colar qualquer coisa sensível.
  • Se sua empresa bloqueia tráfego de saída com firewall, você precisará liberar os domínios de infraestrutura da Docker para o sbx funcionar: login.docker.com, hub.docker.com, api.docker.com, registry-1.docker.io, auth.docker.io, além de alguns endpoints de telemetria e diagnóstico. Isso é separado da política de rede do próprio sandbox.