Resposta rápida
No Copilot CLI, abra uma sessão interativa e execute /sandbox enable. Depois use /sandbox status para confirmar que a proteção está ativa e /sandbox policy para ver quais arquivos, destinos de rede e recursos o agente pode acessar. No aplicativo do GitHub Copilot, ative Sandbox new sessions nas configurações do projeto ou use /sandbox on na sessão atual.
Se um comando falhar, não desligue toda a proteção como primeira tentativa. Execute /sandbox policy COMANDO para inspecionar a política que seria aplicada, libere somente o caminho ou host necessário e tente novamente. O sandbox local entrou em disponibilidade geral em 7 de outubro de 2026 no Copilot CLI, no aplicativo do Copilot e em sessões do VS Code que usam Agent Host.
Por que ativar o sandbox local
Sem o sandbox, comandos iniciados pelo Copilot executam com o mesmo acesso da sua conta de usuário. Eles podem ler, alterar ou excluir arquivos permitidos ao usuário, acessar redes disponíveis e usar credenciais existentes. O sandbox adiciona uma política entre o agente e esses recursos.
A proteção é independente do modelo escolhido. Trocar o modelo não muda os limites de ferramentas. A política pode restringir leitura e escrita no sistema de arquivos, internet, rede local, credenciais Git e GitHub CLI, servidores MCP locais e servidores de linguagem.
Como ativar no Copilot CLI
O comando /sandbox enable ativa a proteção imediatamente na sessão atual e salva a preferência para sessões futuras. Para um teste isolado, inicie o CLI com copilot --sandbox. Em execução programática, a documentação mostra que a opção pode ser combinada com -p.
Confirme o estado real com /sandbox status. O indicador é mais confiável do que assumir que uma preferência salva foi aplicada, pois uma máquina sem os requisitos pode recusar ou desativar a proteção naquela sessão conforme a política efetiva.
- Abra o Copilot CLI dentro do repositório que será usado.
- Execute /sandbox enable.
- Execute /sandbox status e confirme que a sessão usa o sandbox.
- Execute /sandbox policy para revisar caminhos, rede, credenciais e observações.
- Teste primeiro um comando de leitura, como consultar o status do repositório.
Como ativar no aplicativo do Copilot e no VS Code
No aplicativo do GitHub Copilot, abra Settings, selecione o projeto e ative Sandbox new sessions. Essa configuração vale para novas sessões locais do projeto. Para mudar apenas a sessão ativa, use /sandbox on ou /sandbox off, respeitando eventuais políticas da empresa.
No VS Code, a disponibilidade geral cobre sessões que usam Agent Host. A documentação oficial direciona a configuração dos comandos de terminal do agente para as opções do próprio VS Code. Confirme que o cliente está atualizado e verifique o indicador da sessão antes de tratar um bloqueio como falha do GitHub.
Entenda a política padrão antes de liberar acesso
No Copilot CLI, comandos isolados podem escrever no diretório de trabalho e em pastas temporárias. Dentro de um repositório Git, os metadados em .git também ficam graváveis, enquanto partes do repositório acima do diretório atual podem ser apenas legíveis. Outros caminhos ficam bloqueados até receberem uma regra explícita.
O acesso de saída à internet vem habilitado por padrão no CLI, enquanto a rede local fica desabilitada. Credenciais Git e gh também ficam habilitadas por padrão, mas são mascaradas e fornecidas por um proxy para destinos aprovados. Revise essas opções em /sandbox config em vez de supor que um comando herda livremente tudo da sua sessão normal.
- Conceda escrita apenas ao repositório e aos diretórios realmente necessários.
- Negue acesso a arquivos de ambiente, chaves, backups e pastas de clientes quando possível.
- Mantenha a rede local bloqueada se a tarefa não precisa alcançar bancos, painéis ou serviços internos.
- Desative credenciais Git ou gh quando a tarefa não precisa publicar, criar pull request ou acessar conteúdo privado.
Requisitos no Windows, Linux e macOS
No Windows, o GitHub exige uma versão recente do Windows 11 com suporte ao backend BaseContainer e atualizações específicas documentadas. No Linux, o requisito básico inclui bubblewrap 0.5.0 ou posterior e slirp4netns no PATH; controles de rede também dependem de util-linux, iptables e acesso a /dev/net/tun.
No macOS, o backend usa Seatbelt e a documentação recomenda macOS 15 ou posterior. O CLI não bloqueia automaticamente uma versão mais antiga, mas o GitHub informa que ela não é testada. Como cada sistema usa um mecanismo diferente, a mesma política pode ter limitações distintas.
Como corrigir comando bloqueado
Um acesso negado pode ser a proteção funcionando. Antes de conceder uma exceção, confirme qual regra bloqueou o comando e se o recurso é realmente necessário. O comando /sandbox policy npm install, por exemplo, mostra a política prevista sem executar a instalação.
Se o bloqueio vier de uma configuração gerenciada, somente o administrador pode alterá-la. Se a mensagem indicar dependência do sistema ou versão incompatível, atualize o host e reinicie o Copilot CLI. Uma tentativa fora do sandbox amplia o acesso daquele comando; desligar o sandbox na sessão amplia o acesso dos comandos seguintes também.
- Execute /sandbox status para confirmar o estado da sessão.
- Execute /sandbox policy COMANDO para inspecionar a política sem rodar a ação.
- Abra /sandbox config e conceda somente o caminho, host ou credencial indispensável.
- Reinicie a sessão quando a mudança exigir uma nova política efetiva.
- Repita o comando e registre a exceção aprovada para revisão posterior.
MCP, LSP e credenciais exigem cuidado próprio
No Copilot CLI, servidores MCP locais e servidores de linguagem ficam dentro do sandbox por padrão. Isso limita os processos locais iniciados pelo agente. Servidores MCP remotos não são sandboxados porque executam fora da máquina; seus próprios controles de autenticação, autorização e auditoria continuam necessários.
Uma ferramenta pode falhar ao usar Git ou gh se não respeitar o proxy ou o certificado temporário usado para mascarar credenciais. Nesses casos, valide compatibilidade antes de abrir acesso amplo. Nunca copie tokens para o prompt, arquivo de configuração do projeto ou log para contornar o problema.
O que o sandbox não garante
O sandbox local usa controles do sistema operacional e fica no lado mais leve do espectro de isolamento. Ele não transforma cada comando em uma máquina virtual ou contêiner completo. Os recursos disponíveis e a força de algumas regras variam entre Windows, Linux e macOS.
O GitHub também documenta que as ferramentas de arquivo internas do CLI executam dentro do processo principal. Como o sistema operacional não intercepta essas operações da mesma forma, essas ferramentas verificam a política por código, em melhor esforço. Sandboxing reduz impacto, mas não substitui revisão de comandos, permissões mínimas, backups e proteção de segredos.
Limitações e próxima ação útil
Este guia foi verificado em 8 de outubro de 2026. O sandbox local está em disponibilidade geral, mas a proteção vem desativada por padrão quando não existe uma política empresarial exigindo seu uso. O sandbox de nuvem é um recurso diferente, com isolamento e cobrança próprios, e não deve ser confundido com a execução local.
Ative o sandbox em um repositório de teste, confira /sandbox status e /sandbox policy e execute uma tarefa curta que leia arquivos, instale uma dependência e consulte um serviço permitido. Depois bloqueie um caminho sensível e confirme que o acesso falha. Só então aplique uma política equivalente aos projetos reais e decida quais exceções a equipe poderá aprovar.
Faça o próximo teste
Fontes consultadas
Os links abaixo servem para conferir conceitos, orientações oficiais e o critério editorial usado neste conteúdo.
- Local sandboxing for GitHub Copilot now generally availableGitHub Changelog
- About cloud and local sandboxes for GitHub CopilotGitHub Docs
- Using local sandboxingGitHub Docs
- Configuring local sandbox settingsGitHub Docs
- Microsoft eXecution ContainerMicrosoft
- GitHub StatusGitHub