O sandbox local do GitHub Copilot já está disponível de forma geral em Copilot CLI, no app do Copilot e no VS Code: limita quais arquivos, redes e credenciais os comandos executados pelo agente na sua máquina podem usar. O GitHub anunciou isso em 7 de outubro de 2026. Vem incluído na licença do Copilot sem custo adicional e está desativado por padrão, então nada muda até que você o ative.
A funcionalidade não é nova: entrou em visualização pública em 2 de junho, e aqui no yoDEV já escrevemos sobre por que os sandboxes são a peça que faltava para deixar rodar agentes de verdade e sobre a tecnologia da Microsoft que está por baixo. O que é novo é que agora está GA, está documentado e funciona igual em três superfícies. Este artigo é metade prática: como ativá-lo, como ver o que bloqueia, como abri-lo sem jogá-lo no lixo e do que não te protege.
O que é um sandbox e o que é o sandbox local do GitHub Copilot?
Um sandbox é um ambiente isolado onde um programa é executado com acesso limitado ao resto do sistema: só pode ler, escrever e conectar-se ao que a política permite. O sandbox local do GitHub Copilot (local sandboxing na documentação em inglês) aplica essa ideia aos comandos e ferramentas que o Copilot executa por você: comandos de shell, busca de arquivos e, por padrão, os servidores MCP e de linguagem (LSP) locais. Sem ele, esses comandos rodam com todos os privilégios do seu usuário: podem ler, escrever e deletar tudo que você pode, alcançar qualquer rede que sua máquina alcança e usar suas credenciais sem restrições.
Por baixo está o Microsoft eXecution Container (MXC). O Copilot declara uma sandbox policy — quais caminhos podem ser lidos ou escritos, se há acesso à rede, etc. — e o MXC a traduz para o mecanismo de isolamento nativo de cada sistema operacional:
- macOS: Seatbelt
- Linux: bubblewrap (
bwrap) - Windows: o nível BaseContainer do backend ProcessContainer, em versões recentes do Windows 11
O GitHub também oferece sandboxes na nuvem, que são outro produto: toda a sessão roda em um ambiente Linux efêmero hospedado pelo GitHub, construído sobre Azure Container Apps Sandboxes. No momento da publicação desta nota, os sandboxes na nuvem estavam em visualização pública e requeriam uma opção experimental.
Quanto custa? O sandbox do GitHub Copilot é grátis?
O sandbox local sim: a documentação do GitHub indica que está incluído na licença padrão do Copilot sem custo adicional. No momento da publicação desta nota, nem o changelog nem a documentação detalhavam quais planos individuais cobre.
Os sandboxes na nuvem são cobrados por uso, com três medidores:
| Medidor | Unidade | Preço (USD) |
|---|---|---|
| Computação | segundo de computação | $0.000024 |
| Memória | GiB por segundo | $0.000003 |
| Armazenamento (snapshots de sessões interrompidas) | GiB por mês | $0.005 |
Em organizações, os sandboxes na nuvem vêm desativados: um administrador deve ativar a política Cloud Sandbox access antes que os membros possam usá-los.
Funciona no Windows 11, macOS e Linux?
Sim, mas os requisitos mudam segundo o sistema operacional e, ligeiramente, segundo a superfície. Estes eram os requisitos no momento da publicação:
Copilot CLI e app do Copilot
- macOS: recomenda-se macOS 15 (Sequoia) ou posterior. Versões anteriores não são bloqueadas, mas não foram testadas.
- Linux: bubblewrap 0.5.0 ou posterior e
slirp4netnsno seuPATH. Se a política permite tráfego de saída, a documentação também exigeunshare/nsenterde util-linux 2.35+,iptablescom o backendnf_tablese acesso a/dev/net/tun. - Windows: Windows 11 25H2 com KB5124010 ou posterior, ou 26H1 com KB5124006 ou posterior.
VS Code (Agent Host)
- macOS: sem requisitos adicionais.
- Linux e WSL2:
bubblewrapesocat(sudo apt-get install bubblewrap socatem Debian/Ubuntu). WSL 1 não é compatível. - Windows: a atualização de segurança de 8 de setembro de 2026 (KB5124008 para 24H2/25H2, KB5124012 para 26H1). No momento da publicação, VS Code marcava o suporte no Windows como experimental.
Cuidado: se você procurar por “sandbox Windows 11”, é provável que encontre o Windows Sandbox, a máquina virtual descartável do Windows. É outra coisa; o sandbox do Copilot não usa uma VM.
Se sua máquina não puder aplicar a política solicitada, o sandbox falha de forma segura: o comando dá erro em vez de ser executado sem proteção. Na CLI, uma preferência salva é desativada para essa sessão com um aviso, e /sandbox enable é rejeitado.
Como ativar o sandbox no Copilot CLI?
Dentro de uma sessão do Copilot CLI, execute:
/sandbox enable
O sandbox se aplica imediatamente a essa sessão e continua ativo nas sessões interativas e programáticas seguintes até que você execute /sandbox disable. A escolha é salva como sandbox.enabled em ~/.copilot/settings.json. As sessões que você já tinha abertas em outros terminais não a usam até que você as reinicie (por exemplo, com copilot --continue) ou execute /sandbox enable nelas.
Os comandos disponíveis:
| Comando | O que faz |
|---|---|
/sandbox status |
Indica se essa sessão realmente está no sandbox |
/sandbox policy [COMANDO] |
Mostra os caminhos, a rede e as capacidades efetivas, opcionalmente para um comando, sem executá-lo |
/sandbox ou /sandbox config |
Abre a configuração interativa (abas General, Credentials, Filesystem, Network) |
/sandbox enable / /sandbox disable |
Ativa ou desativa |
Para uma única sessão, sem tocar sua preferência salva, use --sandbox (ou --no-sandbox). Também funciona em modo programático:
copilot --sandbox -p "PROMPT"
Quando ativo, a barra de status mostra sandbox enabled.
Como ativar no app do Copilot?
Para a sessão atual:
/sandbox on
e /sandbox off para desativar. Para que esse seja o comportamento padrão de um projeto, abra Settings na barra lateral, escolha o projeto em “Projects” e, em “Sandbox”, ative Sandbox new sessions. Diferentemente da CLI, /sandbox sem argumentos não abre nenhuma tela de configuração. As mudanças de política se aplicam a novas sessões; para aplicá-las a uma sessão aberta sem perder o histórico, use /restart-session.
Como ativar no VS Code?
Na configuração da máquina onde o agente é executado:
{
"chat.agent.sandbox.enabled": "on"
}
Depois, inicie uma nova sessão do Agent Host. Para mudá-lo apenas na sessão atual, abra Permissions e escolha Sandboxing for terminal. Isso se aplica apenas a sessões do Agent Host; o harness Local herdado e as implementações de terminal personalizadas não usam essa configuração da mesma forma.
Um detalhe importante no VS Code: o sandbox é independente do nível de permissões. Mesmo que você escolha Allow all, ele continua restringindo os processos.
O que o sandbox permite por padrão?
No Copilot CLI, a política padrão foi pensada para que o trabalho normal de desenvolvimento continue funcionando:
- Sistema de arquivos: leitura e escrita no seu diretório de trabalho, nas pastas temporárias e no
.gitdo repositório; apenas leitura no resto do repositório acima do seu diretório de trabalho; leitura em certas localizações do sistema e de ferramentas de desenvolvimento, e escrita em alguns caches de compilação e de pacotes. Não inclui sua pasta pessoal completa. - Rede: internet de saída ativada, rede local desativada. No app do Copilot, ambas as opções de rede vêm ativadas.
- Credenciais: Git e
ghfuncionam, mas os comandos dentro do sandbox apenas veem valores de substituição. Um proxy local muda-os para as credenciais reais apenas para destinos HTTPS aprovados: o host original no caso do Git, egithub.com,api.github.comeuploads.github.comno caso degh.
A opção Allow dev tool access, ativada por padrão, merece um segundo olhar. Dá acesso de leitura à configuração e aos caches de ferramentas de desenvolvimento, incluindo registros de pacotes e tokens que guardam. É o que permite que npm install funcione dentro do sandbox, e é a primeira coisa a desativar se você quer uma política rigorosa e está disposto a conceder caminhos manualmente.
Como ver o que o sandbox vai bloquear antes de bloqueá-lo?
Use /sandbox policy seguido do comando que você vai executar:
/sandbox policy npm install
Mostra os caminhos e a configuração de rede que esse comando receberia, sem executá-lo, e em Notes indica qualquer ajuste que não pôde ser aplicado. Quando algo falha, a ordem que o GitHub recomenda é: /sandbox status, depois /sandbox policy e, por fim, conceder apenas o caminho ou o host específico em /sandbox config. Agregar um diretório com /add-dir não dá acesso dentro do sandbox.
Há uma armadilha pouco óbvia: se você bloquear um caminho que ainda não existe — por exemplo, um .env que você pensa criar depois — Copilot CLI cria um diretório com esse nome antes de executar o comando. Se o que você queria bloquear era um arquivo, crie-o primeiro.
No VS Code, /sandbox policy gera um relatório sandbox-policy.md da sessão.
Como abrir o sandbox sem desativá-lo?
Conceda exatamente o que a tarefa precisa, em vez de desativar o sandbox ou aprovar uma exceção para toda a sessão.
Sistema de arquivos: em /sandbox config → Filesystem → User-configured paths, pressione A, digite um caminho absoluto e escolha Read/Write, Read-Only ou Denied. No VS Code, o equivalente é:
{
"chat.agent.sandbox.fileSystem.userConfiguredPaths": {
"readwritePaths": ["/path/to/build-output"],
"readonlyPaths": ["/path/to/shared-source"],
"deniedPaths": ["/path/to/sensitive-data"]
}
}
Rede: as regras por host estão em Network → Proxy and blocking → Host rules. Três regras que vale conhecer antes de adicionar qualquer uma: Deny sempre vence sobre Allow; um domínio negado também bloqueia seus subdomínios; e tão logo você adicione uma única regra Allow, a lista se torna uma lista branca: qualquer host que você não tenha permitido fica bloqueado.
Tokens de API: você pode mascarar variáveis de ambiente adicionais para que as ferramentas dentro do sandbox apenas vejam um valor de substituição, e o proxy injete o valor real apenas nos hosts que você indicar:
{
"sandbox": {
"enabled": true,
"credentials": {
"envVars": {
"EXAMPLE_API_TOKEN": {
"injectHosts": ["api.example.com"]
}
}
}
}
}
O mascaramento só funciona se a ferramenta envia o valor em um cabeçalho HTTPS, como Authorization ou X-Api-Key, ou como senha em autenticação Basic. Não funciona com HTTP sem criptografia, corpos de requisição, URLs nem requisições assinadas.
Sobre as exceções (bypass): quando um comando fica bloqueado, Copilot pode oferecer para tentar novamente fora do sandbox, e essa opção vem ativada por padrão. Uma exceção aprovada também pula o mascaramento de credenciais: esse comando roda com seus segredos reais em seu ambiente. Aprove-as uma por uma, e apenas quando você entender o que o comando vai fazer.
Do que o sandbox local não te protege?
Esta é a seção que vale ler antes de dizer ao seu time de segurança “nossos agentes rodam em um sandbox”. O sandbox local é uma barreira real e útil, mas limitada, e tanto o GitHub quanto a Microsoft são explícitos sobre seus limites:
- Não é uma máquina virtual nem um contêiner. A documentação do GitHub o coloca na ponta leve do espectro de isolamento: restringe o que um processo pode ler, escrever e alcançar, mas o comando continua rodando na sua máquina, com sua conta. A documentação do VS Code acrescenta que não substitui a segurança do endpoint.
- MXC ainda se apresenta como uma visualização bem antecipada. No momento da publicação desta nota, o README do repositório microsoft/mxc alertava que nenhum perfil de MXC deve ainda ser tratado como um limite de segurança, e que algumas políticas geradas são sabidamente demasiado permissivas. A integração no Copilot é GA; o projeto que está por baixo ainda remove esse aviso.
- No Windows, as regras de rede dependem de que o programa coopere. No macOS e Linux, o sandbox força toda conexão a passar pelo proxy local. No Windows depende de que os programas respeitem a configuração de proxy, então um que a ignore pode conectar-se diretamente e pular suas regras de host.
- As ferramentas de arquivos integradas da CLI não são isoladas pelo sistema operacional. Rodam dentro do processo da CLI, que não está no sandbox, e verificam a política por sua conta na medida do possível.
- Os servidores MCP remotos nunca passam pelo sandbox. Apenas os locais.
- Os valores padrão priorizam a produtividade: internet de saída ativada, acesso a ferramentas de desenvolvimento (incluindo tokens de registros) ativado e solicitações de exceção ativadas.
Nada disso é um argumento para não ativá-lo. Passar de “o agente tem tudo que tenho” para “o agente tem o diretório de trabalho e uma lista de exceções auditada” reduz muito a exposição. É um argumento para descrevê-lo com precisão e para decidir quais valores padrão ajustar.
Se você precisa de um isolamento mais forte, cerque o trabalho com uma barreira de contêiner ou VM: um sandbox na nuvem, ou Dev Containers com agentes de IA no VS Code.
Como obrigar todo o time a usar o sandbox?
Com as enterprise managed settings, gerenciadas do servidor, por MDM ou via arquivo. Os valores gerenciados aparecem como (managed) em /sandbox e o desenvolvedor não pode mudá-los. Três chaves definem a postura:
sandbox.enabled: exige o sandbox.sandbox.failIfUnavailable: combinado comsandbox.enabled, faz a CLI bloquear as solicitações ao modelo e a execução de ferramentas se a máquina não puder aplicar o sandbox, em vez de continuar sem ele.sandbox.allowBypassemfalse: sem exceções por comando nem desativação para a sessão.
As regras de host empresariais apenas podem reduzir a lista branca de um desenvolvedor, nunca ampliá-la. No VS Code, administradores devem usar os Copilot managed settings em vez das políticas de dispositivo herdadas; no momento da publicação, VS Code marcava essa aplicação gerenciada como visualização.
E você? Você deixa seus agentes de código executarem comandos em sua máquina sem supervisão, ou aprova cada um?
- Já os rodo dentro de um sandbox ou contêiner
- Aprovo os comandos um por um
- Os deixo rodar com as permissões do meu usuário
- Prefiro outra opção (conta aí qual)
Comente abaixo ou, se este artigo chegou para você por email, responda diretamente ao email: sua resposta é publicada aqui.
Relacionado: Sandboxes para Copilot: A Peça que Faltava para Deixar Rodar Agentes de Verdade