Onde rodar seu agente de código: sandbox local, contêiner remoto ou nuvem?
Imagine uma correção pequena no frontend: ajustar um botão, instalar as dependências e rodar os testes. Você passa a tarefa para um agente de código. Antes do primeiro comando, porém, ele já precisa de um lugar para trabalhar. Se rodar no seu notebook, terá acesso a quê? Se for para um contêiner remoto, os testes vão usar a mesma configuração do projeto? E, na nuvem, quais arquivos terão de sair da sua máquina?
Essa escolha costuma ficar escondida atrás do botão "iniciar sessão". Eu prefiro tratá-la como parte da tarefa. O mesmo pedido pode ser razoável num ambiente restrito e arriscado num shell com acesso ao seu diretório pessoal e a credenciais de produção.
Primeiro, escreva o contrato da tarefa
Para a correção do botão, eu anotaria antes de escolher a ferramenta:
- O agente pode ler e alterar o repositório de trabalho, mas não outros projetos.
- Precisa da versão de Node e das dependências usadas pelo projeto para rodar teste e lint.
- Pode acessar a rede apenas se a instalação ou o teste realmente dependerem dela. Quais destinos são necessários?
- Não precisa de
.envde produção nem de tokens de deploy. - Entrega um diff e o resultado dos testes; publicar, fazer merge ou implantar exige aprovação separada.
Isso é uma proposta de escopo para o seu fluxo, não uma configuração que todas as ferramentas ofereçam pronta. Se você não consegue impor um dos limites, trate-o como risco conhecido. Não basta colocá-lo no prompt e presumir que o ambiente fará cumprir a regra.
Sandbox local: rápido, desde que a restrição esteja ativa
Trabalhar perto do repositório reduz o tempo de preparação. Também deixa o agente perto dos arquivos e credenciais do seu dia a dia. Para tarefas curtas, faz sentido experimentar um sandbox local, mas só depois de verificar a política da sessão que vai executar os comandos.
O sandbox local anunciado para o GitHub Copilot app ilustra o cuidado: está em preview, vem desligado por padrão e é configurado por projeto para sessões locais. A política pode restringir acesso a arquivos, rede e credenciais. No caso do shell em sandbox, se o sistema operacional não conseguir aplicar a política solicitada, a execução falha em vez de seguir sem a restrição. É um comportamento útil, mas não autoriza concluir que toda ferramenta do agente, toda sessão anterior ou um host remoto esteja protegida do mesmo jeito.
No exemplo do botão, eu conferiria se a sessão nova está mesmo sob a política esperada, se o diretório permitido corresponde ao projeto e se os segredos não estão acessíveis pelo processo. Se não for possível confirmar isso, não daria ao agente uma tarefa que dependa desse isolamento.
Contêiner remoto: bom para repetir o ambiente, não para dispensar permissões
Se a correção só passa nos testes com a toolchain do servidor de desenvolvimento, um Dev Container remoto pode ser mais útil do que replicar tudo no notebook. O VS Code 1.139 trouxe suporte gradual a sessões da Agents Window em Dev Containers de projetos acessados por SSH, Tunnel ou WSL. A ideia prática é executar o trabalho com as dependências do projeto no ambiente em que elas já estão preparadas.
Há trabalho de configuração: preparar o host, o contêiner e o acesso ao repositório. Em um host compartilhado, também é preciso decidir quais diretórios, recursos e destinos de rede a sessão pode alcançar. Um contêiner ajuda a repetir a toolchain; ele não vira automaticamente uma fronteira de segurança. Montar credenciais do host dentro dele, por exemplo, desfaz parte do cuidado que motivou a mudança.
Eu escolheria essa opção quando o ambiente remoto já faz parte do projeto e reproduzir os testes localmente é a parte difícil. Ainda assim, verificaria os acessos concedidos ao contêiner antes de deixar o agente instalar ou executar qualquer coisa.
Ambiente gerenciado: menos infraestrutura, outras perguntas
Para uma tarefa longa, pode valer usar um sandbox hospedado. A Agents API da OpenAI oferece essa possibilidade para trabalhar com código, arquivos e artefatos, além de admitir ambientes em infraestrutura própria ou de parceiros. Ter a opção gerenciada não elimina a decisão sobre os dados que serão enviados para lá.
Antes de usá-la na mesma correção, eu perguntaria: o repositório contém dados que não podem sair do ambiente atual? Quais arquivos o agente realmente precisa? Como vou inspecionar o diff e trazer os artefatos de volta? Qual é o custo aceitável de uma sessão que pode continuar por bastante tempo? Credenciais e acesso à rede precisam de uma decisão explícita, não de uma suposição de que "a nuvem cuida disso".
Se a equipe não quer manter o ambiente de execução de tarefas demoradas, o gerenciado pode compensar. Se o trabalho depende de dados locais sensíveis ou de um teste que só roda na infraestrutura da equipe, talvez não seja o melhor ponto de partida.
Uma regra de escolha para o próximo trabalho
Para uma alteração curta, com dependências simples e uma política local que você conseguiu verificar, comece pelo sandbox local. Se o principal obstáculo for repetir a toolchain e o projeto já tiver um host remoto preparado, avalie o contêiner. Se a duração e a manutenção do ambiente pesarem mais, considere o gerenciado depois de definir o que pode ser enviado e como o resultado volta para revisão.
Em qualquer uma das opções, use o menor acesso que permita concluir a tarefa. Rode os testes na toolchain escolhida, examine o diff e mantenha uma aprovação humana antes de um efeito externo, como fazer merge ou deploy. O lugar onde o agente roda muda o que ele encontra e o que pode afetar; o prompt, sozinho, não estabelece esses limites.