Agentes de programação ficaram mais úteis quando passaram a executar comandos, consultar arquivos e alterar projetos. O problema é que a mesma autonomia que acelera um trabalho também pode ampliar um erro: um comando mal interpretado pode apagar arquivos, expor credenciais ou acessar uma rede que não deveria estar disponível. A documentação oficial do GitHub apresenta os sandboxes locais e em nuvem do Copilot como uma camada para reduzir esse risco. Eles não tornam um agente infalível, mas criam limites mais claros para o que uma sessão pode fazer.
O ponto principal é separar conveniência de isolamento. No modo local, os comandos continuam sendo executados no computador do desenvolvedor, porém passam por uma política que restringe acesso ao sistema de arquivos, à rede e a outras capacidades. No modo em nuvem, a sessão inteira roda em um ambiente Linux efêmero hospedado pelo GitHub. A escolha depende do tipo de código, dos dados envolvidos e da necessidade de manter o ambiente perto do projeto real.
O que um sandbox muda na prática
Sem sandbox local habilitado, os comandos executados pelo Copilot CLI podem ter os mesmos privilégios do usuário. Isso significa ler, escrever e apagar tudo aquilo que a conta consegue acessar, alcançar serviços disponíveis na rede e, em determinadas situações, usar credenciais presentes no ambiente. A documentação do GitHub deixa esse contraste explícito: a proteção não deve ser confundida com o simples fato de usar uma interface de IA.
Com uma política de sandbox, o desenvolvedor pode definir quais caminhos são legíveis ou graváveis e se o processo terá acesso à rede. Essa delimitação é importante porque um agente costuma encadear tarefas. Um pedido para atualizar dependências, por exemplo, pode envolver busca de arquivos, execução de um gerenciador de pacotes, consulta a um registro e alteração de vários arquivos. A política transforma esse fluxo em algo mais previsível e auditável.
Há também um detalhe operacional: a proteção se aplica aos comandos e serviços que o agente inicia, como buscas de arquivos e, por padrão, servidores MCP e LSP usados pela CLI. Isso reduz a superfície de ação, mas não elimina a responsabilidade de revisar o que será executado. Um projeto comprometido, uma configuração permissiva ou uma instrução ambígua ainda podem produzir resultados ruins dentro dos limites autorizados.
Como funciona o sandbox local
O sandbox local é voltado para quem precisa trabalhar com o repositório que está na própria máquina. O GitHub informa que essa opção usa a tecnologia Microsoft eXecution Container, ou MXC, para oferecer uma interface comum às capacidades de isolamento de cada sistema operacional. A implementação fica no lado mais leve do espectro: ela restringe processos, arquivos e rede, mas não coloca automaticamente os comandos em uma máquina virtual completa.
Esse desenho favorece o fluxo diário. O código continua perto das ferramentas locais, o desenvolvedor pode acompanhar o resultado e a execução não depende de enviar todo o projeto para um ambiente remoto. Em troca, é preciso entender a força da proteção disponível no sistema operacional. A documentação destaca que as tecnologias de isolamento variam e que o sandbox local não deve ser apresentado como equivalente a um hipervisor ou a um contêiner totalmente separado.
Para habilitá-lo durante uma sessão do Copilot CLI, o comando documentado é /sandbox enable. Depois disso, a CLI mantém o sandbox em usos futuros, inclusive programáticos, até que ele seja desativado com /sandbox disable, salvo quando uma política administrada por uma organização impedir a mudança. Em empresas, configurações de servidor, MDM ou arquivos gerenciados podem exigir o sandbox e fazer a sessão falhar de modo fechado quando a proteção não puder ser aplicada.
O suporte varia por plataforma. No macOS, o backend usa Seatbelt e a documentação cita o macOS 15 ou posterior como ambiente testado. No Linux, o backend usa bubblewrap. O texto também alerta para limitações no Windows: determinadas configurações de caminhos negados não podem ser aplicadas pela CLI e o comando sandboxado pode falhar. A consequência prática é simples: teste a política no mesmo sistema que será usado no trabalho, em vez de assumir que uma regra tem o mesmo efeito em toda máquina.
O que muda no sandbox em nuvem
O sandbox em nuvem executa a sessão do Copilot CLI em um ambiente Linux totalmente isolado e efêmero, hospedado pelo GitHub. Cada sessão fica separada do ambiente local e das outras sessões. É uma alternativa interessante para tarefas exploratórias, repositórios de teste ou situações em que o projeto não precisa acessar diretamente arquivos e serviços privados da máquina.
Para iniciar uma sessão desse tipo, a documentação mostra copilot --cloud --experimental. O recurso é experimental e exige que as funcionalidades experimentais estejam habilitadas. Além disso, o modo em nuvem é voltado para sessões interativas: não é possível combiná-lo com os modos programáticos -p ou -i. Isso impede que ele seja tratado como um substituto universal para toda automação de CI.
A sessão em nuvem não altera as sessões futuras por padrão. É necessário pedir o modo cloud a cada nova sessão. Quando o trabalho é interrompido, o ambiente pode gerar um snapshot para retomada; quando a sessão é excluída, o ambiente e o snapshot são removidos. O isolamento traz portabilidade, mas também exige atenção ao ciclo de vida: arquivos temporários, dependências e alterações precisam ser exportados ou aplicados ao destino de forma deliberada.
O acesso depende da autenticação existente do Copilot e, em organizações, de uma política que habilite o Cloud Sandbox access. O custo também é diferente: o sandbox local está incluído no assento padrão do Copilot, enquanto o sandbox em nuvem é cobrado conforme o uso. Antes de adotá-lo em equipe, vale confirmar tanto a permissão administrativa quanto o modelo de faturamento.
Como escolher e testar com segurança
Para código proprietário que precisa permanecer na máquina, o modo local costuma ser o primeiro candidato, desde que a política limite claramente os diretórios e a rede. Para uma exploração descartável, uma reprodução isolada ou um experimento que não precisa dos arquivos locais, o modo em nuvem pode reduzir a exposição do computador. Nenhuma das opções deve ser escolhida apenas porque parece mais automática.
Um teste responsável começa com um repositório sem segredos e uma tarefa pequena. Habilite o sandbox, observe quais comandos são permitidos, confirme que um caminho fora do projeto não pode ser lido e verifique se a rede está de acordo com a política. Em seguida, revise os arquivos modificados e os processos iniciados. Esse ensaio revela incompatibilidades do sistema operacional antes que elas apareçam no projeto de produção.
Também é importante tratar MCP, LSP, scripts de instalação e ferramentas de terceiros como partes do mesmo perímetro. O agente pode estar limitado, mas um serviço auxiliar mal configurado ainda pode receber mais acesso do que deveria. Use permissões mínimas, mantenha credenciais fora do diretório de trabalho e não aceite automaticamente mudanças cuja origem você não consegue explicar.
Limites que continuam exigindo revisão
Sandbox não é sinônimo de revisão de código, controle de dependências ou garantia de que a saída está correta. Ele restringe capacidades; não decide se uma alteração atende ao requisito do projeto. Um comando permitido pode apagar um arquivo autorizado, introduzir uma dependência vulnerável ou gerar uma configuração insegura. A equipe ainda precisa revisar diffs, testes, logs e permissões.
O ganho real está em tornar o raio de ação menor e mais explícito. O GitHub documenta uma opção local integrada ao fluxo de desenvolvimento e uma opção em nuvem com isolamento mais forte e ambiente efêmero. A decisão madura é começar pelo menor acesso necessário, testar a política no ambiente real e ampliar permissões somente quando houver uma necessidade concreta.
Em resumo, o sandbox local aproxima segurança e produtividade para quem trabalha no próprio computador, enquanto o sandbox em nuvem prioriza isolamento remoto e descartável. Os dois modos são úteis, mas têm custos, compatibilidades e limites diferentes. Antes de deixar um agente executar comandos, confira a política, a plataforma, a origem das ferramentas e o caminho de recuperação. A referência oficial do GitHub pode ser consultada em About cloud and local sandboxes for GitHub Copilot.
