O GitHub adicionou em 23 de setembro de 2026 o sandbox local ao GitHub Copilot app. O recurso executa as ferramentas acionadas pelo agente dentro de um isolamento do sistema operacional e permite limitar, por projeto, o acesso a arquivos, rede e credenciais. Ele está em prévia pública, vem desativado por padrão e vale para sessões locais em repositório ou working tree. Não se aplica a sessões em cloud sandbox nem a sessões executadas em host remoto.
Para quem quer habilitar e testar o recurso com segurança, o ponto mais importante é não tratar o botão de sandbox como uma permissão única. Cada projeto tem uma política própria. A política padrão ainda permite várias tarefas de desenvolvimento, por isso a revisão de pastas, rede e credenciais é parte essencial da configuração.
Como habilitar o sandbox local por projeto
- Abra as configurações do GitHub Copilot app.
- Selecione o projeto que será configurado.
- Na seção Sandbox, ative a opção Sandbox new sessions.
- Inicie uma nova sessão local no repositório ou em uma working tree para que o padrão do projeto seja aplicado.
A ativação nas configurações do projeto não altera uma sessão que já está rodando. Em uma sessão local ativa, é possível usar /sandbox on para ligar o isolamento imediatamente. Esse comando cria uma substituição para a sessão atual e não muda o padrão das outras sessões do projeto. Da mesma forma, /sandbox off desativa o isolamento para a sessão, quando a política efetiva permite isso.
Se você alterar regras de arquivos, rede ou credenciais nas configurações do projeto, a nova política será usada em novas sessões ou depois que uma sessão existente for reiniciada. O GitHub documenta /restart-session como forma de reiniciar a sessão preservando o histórico.
O que revisar antes de considerar o projeto isolado
O sandbox local é configurado em três grupos principais. A tabela abaixo resume o comportamento documentado e a decisão prática que merece revisão.
| Área | Comportamento e controles | O que revisar no projeto |
|---|---|---|
| Sistema de arquivos | A sessão tem leitura e gravação no workspace e no diretório de trabalho atual. É possível adicionar caminhos extras de leitura/gravação, caminhos somente leitura e caminhos negados. | Conceda acesso extra apenas quando necessário. Prefira somente leitura para bibliotecas, dados ou pastas de referência que não precisam ser modificados. Use a lista de negação para diretórios sensíveis próximos ao projeto. |
| Internet de saída | O acesso à internet é permitido por padrão e pode ser bloqueado. | Se a tarefa não precisa instalar dependências, consultar APIs ou acessar serviços externos, considere desligar esse acesso para reduzir a superfície disponível ao agente. |
| Rede local | O acesso a loopback e à rede local é permitido por padrão e pode ser bloqueado. | Mantenha apenas quando a sessão precisar conversar com servidor de desenvolvimento, banco local ou outro serviço da rede privada. |
| Credenciais Git | Operações Git HTTPS autenticadas podem usar credenciais dentro do sandbox e esse acesso pode ser desativado. | Desative se a sessão não precisa fazer push ou outra operação autenticada. |
| Credenciais GitHub CLI | O GitHub CLI pode receber autenticação dentro do sandbox e esse acesso pode ser desativado. | Desative quando a sessão não precisa criar pull requests ou executar outras ações autenticadas via gh. |
Uma regra de negação mais específica continua valendo mesmo quando uma pasta pai mais ampla tem acesso concedido. Isso ajuda a proteger uma subpasta sensível sem bloquear todo o diretório de desenvolvimento.
Checklist de menor privilégio para cada projeto
- Pastas: o agente precisa realmente ler ou escrever fora do workspace?
- Somente leitura: um caminho compartilhado pode ser consultado sem permitir alteração?
- Negação: existem chaves, backups, dados pessoais, arquivos de produção ou outros diretórios locais que devem ficar fora do alcance?
- Internet: a sessão precisa acessar registro de pacotes, APIs ou GitHub durante esta tarefa?
- Rede local: é necessário atingir localhost ou serviços da LAN?
- Git: há motivo para expor credenciais autenticadas ao comando executado pelo agente?
- GitHub CLI: a tarefa exige autenticação do gh ou pode terminar antes dessa etapa?
- Política corporativa: alguma opção aparece como gerenciada ou fica mais restrita por regras da empresa?
A política efetiva pode ser mais restritiva que a política escolhida no projeto quando existem configurações administradas pela empresa. Por isso, a tela do projeto mostra a intenção local, mas o comportamento real também depende das regras aplicadas ao ambiente.
Como testar o isolamento sem depender apenas da configuração visual
Depois de ativar o sandbox, faça os testes em uma sessão nova e em um projeto não crítico. O objetivo é confirmar que o que deve funcionar continua funcionando e que o que foi bloqueado falha de maneira previsível.
- Teste o workspace permitido. Peça à sessão para ler um arquivo do projeto e criar ou alterar um arquivo descartável dentro do workspace. A operação deve funcionar quando o projeto mantém o acesso padrão de leitura e gravação.
- Teste um caminho negado. Adicione uma pasta de teste à lista Denied e tente acessá-la a partir da sessão. O acesso deve ser recusado. Não use uma pasta sensível real apenas para provar o bloqueio.
- Teste a internet. Desative Outbound internet e execute uma tarefa que dependa claramente de uma conexão externa, como consultar um registro de pacotes ou um endpoint de teste. A operação deve falhar por falta de conectividade.
- Teste a rede local. Se o projeto usa um servidor local, desative Local network e verifique se a sessão deixa de alcançá-lo. Depois restaure a permissão somente se ela for necessária ao fluxo normal.
- Teste credenciais. Desative Git credentials e GitHub CLI credentials e use uma operação de autenticação em um repositório ou ambiente de teste. O resultado esperado é que ações que dependem dessas credenciais deixem de funcionar dentro do sandbox.
- Reative apenas o necessário. Depois dos testes, volte à política mínima que atende o trabalho real do projeto.
Há uma limitação importante no Linux: a documentação informa que o sandbox do app não consegue controlar de forma independente o acesso à rede local para alguns processos iniciados, como comandos de shell e servidores MCP ou LSP locais. A configuração continua valendo para operações executadas no próprio processo, como certas solicitações web e conexões MCP remotas. Isso significa que o teste de rede local deve levar a plataforma em conta.
O que acontece quando a política não pode ser aplicada
O app aceita a configuração antes de verificar se o sistema operacional consegue impor todas as regras. A checagem acontece quando o primeiro shell em sandbox é iniciado. Se o host não puder aplicar a política solicitada, o shell falha com uma mensagem de plataforma ou política não suportada. Segundo o GitHub, ele não continua executando o comando sem sandbox como fallback silencioso.
Esse comportamento é importante para a revisão de segurança: um erro de sandbox deve ser tratado como falha de execução a investigar, não como sinal de que o agente executou a tarefa com isolamento parcial.
Quando o app pede para executar fora do sandbox
Uma ferramenta pode precisar de um recurso que a política bloqueia. Nesse caso, o GitHub Copilot app pode mostrar uma solicitação para executar fora do sandbox. Dependendo da política efetiva, o usuário pode cancelar, executar aquela operação uma vez fora do isolamento ou desativar o sandbox para o restante da sessão atual.
Executar fora do sandbox amplia o acesso daquela operação e deve ser uma decisão consciente. Em ambientes corporativos, um administrador pode impedir esse tipo de bypass. Desativar temporariamente o sandbox por essa solicitação não altera o padrão do projeto e termina quando a sessão é reiniciada ou reanexada.
Sandbox local não é o mesmo que working tree nem cloud sandbox
Uma working tree separa branch e arquivos de sessões concorrentes, mas não limita, sozinha, o que um comando pode alcançar no restante da máquina. O sandbox local adiciona essa camada de contenção para ferramentas executadas pelo agente.
Já o cloud sandbox roda a sessão em um ambiente isolado hospedado pelo GitHub. O sandbox local continua executando na sua máquina, com controles do sistema operacional sobre arquivos, rede e credenciais. Por isso, escolher entre sessão local e cloud sandbox é uma decisão diferente de ajustar as permissões de um projeto local.
As configurações de sandbox do GitHub Copilot app e do Copilot CLI também são separadas. Ativar ou restringir o sandbox em uma superfície não replica automaticamente a configuração na outra.
Configuração prática recomendada para começar
Para um projeto comum, uma sequência prudente é habilitar o sandbox em novas sessões, manter apenas o acesso de leitura e gravação necessário ao workspace, negar diretórios locais sensíveis, desligar credenciais que não serão usadas e revisar se internet e rede local são realmente exigidas pela tarefa. Em seguida, teste as restrições em uma nova sessão e documente exceções que o projeto precise manter.
O ganho do sandbox é reduzir o alcance de comandos indesejados. Ele não elimina a necessidade de revisar ações do agente, especialmente quando houver pedidos para executar fora do isolamento ou quando o projeto exigir acesso amplo a rede, credenciais e caminhos adicionais.
