Sandbox local do GitHub Copilot chega à disponibilidade geral no CLI, no app e no VS Code

O agente do Copilot agora pode rodar comandos na sua máquina dentro de um limite de segurança, e isso deixou de ser prévia 😀

Fala aí, beleza? O GitHub anunciou em 7/10/2026 a disponibilidade geral (GA) do sandbox local do GitHub Copilot

O recurso cobre o Copilot CLI, o app GitHub Copilot e as sessões do VS Code que usam Agent Host

O anúncio saiu no changelog oficial do GitHub, e é dele (e da documentação oficial) que vêm todos os detalhes deste post

Bora ver o que mudou na prática?

O que é o sandbox local do GitHub Copilot e o que ele controla

Primeiro o porquê, beleza?

Sem sandbox, os comandos de shell que o Copilot dispara rodam direto na sua máquina, com o MESMO acesso da sua conta de usuário

Ou seja: tudo que você pode ler, apagar ou acessar, o agente também pode… os rm -rf da vida inclusos haha

O sandbox local cria uma fronteira de execução em volta disso

Ferramentas e comandos iniciados pelo Copilot passam a rodar com acesso restrito ao sistema de arquivos, à rede, às credenciais e a outros recursos do sistema, seguindo políticas definidas por você ou pela sua organização

Os controles anunciados são estes:

• Arquivos e pastas: limitar o que os comandos do agente podem ler ou alterar
• Rede: controlar o acesso à internet e a redes locais
• Credenciais: controlar o acesso às credenciais do Git e às credenciais do GitHub CLI
• Serviços locais: aplicar o sandbox a ferramentas locais, incluindo servidores MCP locais e language servers, onde houver suporte

Essa parte das credenciais é a que mais pesa no dia a dia

Quem coloca agente pra mexer em issues e pull requests (a mesma dúvida que aparece no Claude Code entre gh CLI ou GitHub MCP) sabe que um token exposto é porta aberta pro seu GitHub inteiro

Outro ponto importante: execução do modelo e isolamento de ferramentas são coisas separadas

A política do sandbox vale para a execução das ferramentas seja qual for o modelo que o Copilot estiver usando 🙂

Como funciona o isolamento com o Microsoft eXecution Container (MXC)

Por baixo dos panos, quem faz o trabalho pesado é o Microsoft eXecution Container, o MXC

O fluxo é assim: o Copilot declara uma política (quais caminhos podem ser lidos ou escritos, se tem acesso à rede e por aí vai) e o MXC aplica essa política usando o mecanismo de isolamento do próprio sistema operacional

E que mecanismo é esse? Depende do sistema:

• Windows: camada BaseContainer do backend ProcessContainer (exige versões recentes do Windows 11)
• macOS: Seatbelt
• Linux: bubblewrap

Pensa no MXC como um tradutor: você escreve a regra uma vez só e ele converte pro "idioma" de segurança de cada plataforma

Uma política única, controles nativos em Windows, macOS e Linux, sem você precisar manter três configurações diferentes

Vale lembrar que esse é um isolamento mais leve: ele restringe o que o processo lê, grava e alcança na rede, mas não roda os comandos dentro de uma máquina virtual ou de um contêiner separado

Da prévia no app à disponibilidade geral

Especificamente no app GitHub Copilot, em 23/9/2026 o GitHub levou o sandbox local até ele como prévia pública

Naquela fase, no app, ele vinha desligado por padrão e era configurado por projeto

Com a GA de 7/10/2026, o sandbox local passa a valer oficialmente no Copilot CLI, no app GitHub Copilot e nas sessões do VS Code com Agent Host

Como ativar o sandbox local no Copilot CLI

Aqui vale um aviso logo de cara: no Copilot CLI o sandbox local vem desligado por padrão

Isso é diferente do app GitHub Copilot, onde a configuração por projeto continua sendo o mecanismo que define o padrão do sandbox local para novas sessões: as configurações do CLI e do app são separadas, ativar em um não muda o outro

Até você ativar, os comandos de shell do Copilot continuam rodando direto na máquina com o mesmo acesso da sua conta

Os comandos abaixo valem só para o Copilot CLI, dentro de uma sessão interativa:

1. Ativar o sandbox

/sandbox enable

Erro comum deste passo: assumir que a GA ligou tudo sozinha. Não ligou, no CLI é você quem ativa

2. Abrir as configurações interativas

/sandbox config

O comando /sandbox sozinho também abre a mesma tela de configuração

3. Conferir a política efetiva

/sandbox policy

Ele mostra os caminhos, as configurações de rede e as capacidades efetivas para o diretório atual

Erro comum deste passo: ajustar a config e seguir sem conferir aqui. Se a sua organização tem alguma política aplicada por fora, é esse comando que mostra o resultado final, não a sua configuração isolada

Depois de ativado, o sandbox vale para todas as sessões do Copilot CLI até ser desativado ou desligado em uma sessão específica

Quais são as permissões padrão do sandbox no CLI?

Por padrão, com o sandbox ligado:

• Escrita liberada: diretório de trabalho atual e pastas temporárias (em repositório Git, os metadados do Git também ficam graváveis, e alguns caches de build e de pacotes também)
• Leitura liberada: alguns locais do sistema e de ferramentas de desenvolvimento: mas NÃO a sua pasta de usuário (home) inteira
• Rede: internet de saída ligada por padrão, rede local desligada
• Bloqueado: o resto fica bloqueado

Na prática, o agente mexe no projeto em que você está e em alguns pontos específicos do sistema, sem ganhar leitura livre pela sua home inteira nem acesso ao restante da máquina 😛

E no app GitHub Copilot e no VS Code?

No app GitHub Copilot, as configurações do projeto continuam sendo o que define o padrão do sandbox local pra novas sessões locais, separado da configuração do CLI

E tem um detalhe que passa batido: dentro de uma sessão local já ativa no app, dá para mudar o sandbox daquela sessão específica, sem alterar o padrão salvo do projeto

Já pro VS Code, a própria documentação do GitHub aponta a página sobre sandbox de comandos de terminal do agente, na documentação do VS Code, como ponto de partida pras sessões que usam Agent Host

Tome cuidado com tutorial de terceiro ensinando menu do app ou do VS Code: confira sempre na doc oficial, porque comportamento de UI muda rápido

O que muda para empresas e times

Pra empresa, essa é a parte mais massa da notícia

Configurações gerenciadas podem tornar o sandbox obrigatório e impor políticas que o desenvolvedor não consegue afrouxar

No Copilot CLI isso é bem concreto: se a política gerenciada exige o sandbox, nem a configuração comum, nem a opção --no-sandbox desligam o sandbox, e o /sandbox disable normalmente também é recusado

A única exceção é quando a própria política efetiva permite esse bypass: nesse caso o /sandbox disable desliga o sandbox só no restante da sessão atual, sem alterar a política salva da empresa

E a distribuição pode ser centralizada: a empresa consegue exigir o sandbox e impor a configuração por meio de configurações gerenciadas no servidor, por MDM ou baseadas em arquivo

Quem ganha com isso?

Times que querem dar mais autonomia ao agente sem expor segredos nem a rede interna

É como contratar um dev rápido pra caramba, mas entregar a ele só a chave da sala do projeto, e não do prédio inteiro haha

Sandbox local x sandbox na nuvem do Copilot

O GitHub tem dois tipos de sandbox, e é fácil confundir

Se liga na diferença:

Resumindo: o local protege a sua máquina enquanto o agente trabalha nela, o da nuvem tira a sessão da sua máquina de vez

Limitações e o que conferir antes de adotar

Nem tudo é automático, então antes de sair confiando cegamente:

• MCP e language servers: a cobertura de servidores MCP locais e language servers depende de suporte, ela não é garantida pra qualquer ferramenta
• Desligado por padrão no CLI: quem não ativa segue rodando com o acesso total da própria conta
• Isolamento leve: o sandbox local restringe leitura, escrita e rede, mas não roda os comandos dentro de uma VM ou contêiner separado
• Detalhes de política e plataforma: o comportamento exato em cada sistema e cada produto deve ser conferido na documentação oficial antes de padronizar no time

Já vi muita gente achar que "tem sandbox" só porque o recurso existe…

Existir não é o mesmo que estar ligado, faça o teste com /sandbox policy 😉

Vale a pena usar o GitHub Copilot?

Tá chegando agora no Copilot e quer entender a ferramenta antes de mexer em sandbox e políticas? Bora ver ele em uso na prática:

Conclusão: um passo para agentes mais autônomos com limites claros

A GA do sandbox local do GitHub Copilot resolve um problema real: deixar o agente trabalhar com mais autonomia sem que ele tenha o mesmo poder que você tem na máquina

O agente ganha liberdade pra rodar comandos, mas dentro de limites claros de arquivos, rede e credenciais, definidos por você ou pela sua empresa

Tudo isso com uma política única, aplicada por controles nativos de Windows, macOS e Linux via MXC, e sem custo adicional no Copilot

O próximo passo depende de onde você está:

• Usa o Copilot CLI? Ative com /sandbox enable e revise o resultado com /sandbox policy
• Cuida de um time? Leia a documentação oficial About cloud and local sandboxes for GitHub Copilot antes de impor políticas gerenciadas

E aí, vai ligar o sandbox ou vai seguir no modo 100% confiança no agente? haha

Até o próximo post! 🙂