Docker Sandbox: onde deve ficar o código do agente? Três arranjos de checkout com o sbx

A fonte trata de uma decisão que costuma passar batida ao colocar um agente num sandbox: onde fica o código. O sbx suporta três arranjos. No primeiro, o sbx run monta o diretório do projeto no mesmo caminho absoluto dentro do sandbox. O agente edita a working tree que você já usa, o Git funciona dos dois lados e o hot reload do host enxerga as mudanças. O custo é de coordenação: trocar de branch muda o que o agente vê, e suas edições entram no trabalho dele. As dependências instaladas também são compartilhadas, e binários nativos (como o esbuild) podem rodar no sandbox Linux e quebrar num host macOS ou Windows.

No segundo arranjo, cada tarefa ganha um Git worktree e uma branch, montados em sandboxes próprios. Montar só um linked worktree esbarra numa limitação do Git: o arquivo .git aponta para metadados fora do mount, então status, branch e commit só funcionam no host. O modo clone do sbx resolve isso. Ele cria um clone independente com Git dentro do sandbox e monta o código do host como somente leitura. O resultado volta por fetch no remote que o sbx adiciona no host, ou por push do agente ao remote do repositório. No terceiro arranjo, o sandbox é mountless: o repositório é clonado lá dentro, sem ligação com a cópia local. O fluxo lembra uma máquina de desenvolvimento remota, com sbx exec ou editor via SSH, e o trabalho sai por push. Para prévia de uma aplicação web, é preciso publicar a porta, e o servidor deve escutar em 0.0.0.0. Remover o sandbox apaga o que existir só nele, então faça push ou copie antes. A fonte também cita montar vários diretórios, com leitura apenas para repositórios de referência.

A cobertura anterior mostra o sbx por outro ângulo. Em 15 de abril de 2026, o CEVIU noticiou "Executando agentes de IA com templates customizados usando o sandbox Docker", sobre imagens OCI customizadas com toolchains pré-instaladas para evitar reinstalação a cada sessão, com agentes isolados em microVMs. Em 12 de fevereiro de 2026, "Os Dois Padrões Arquitetônicos para a Conexão de Agentes com Sandboxes" tratou da relação entre agente e sandbox em termos de arquitetura. A notícia de agora desce para a camada do checkout: onde ficam os arquivos e quem controla o Git. É um complemento, não uma mudança de versão do produto.

Para quem opera plataforma de desenvolvimento, a escolha do checkout define a rotina de revisão e a limpeza. Mount direto é simples, mas serve a uma tarefa por vez. Worktree com clone escala para tarefas paralelas, ao custo de diretórios e sandboxes para limpar. Mountless se aproxima de um ambiente remoto efêmero e mantém o host intacto, mas exige disciplina de push. Em pipelines e ambientes compartilhados, o ponto prático é tratar o sandbox como descartável e fazer do remote Git o canal oficial de saída.