Permissões assistidas do GitHub Copilot chegam à disponibilidade geral no CLI, no app e no VS Code

Fala aí, beleza? O GitHub anunciou em 26/10/2026, no changelog oficial, que as permissões assistidas (assisted permissions) do Copilot chegaram à disponibilidade geral no Copilot CLI, no app do GitHub Copilot e no VS Code

Na prática, quando o Copilot pede pra rodar um comando, acessar um caminho do sistema de arquivos ou abrir uma URL, um LLM avalia o pedido: o que for classificado como claramente seguro segue sozinho, e o resto continua esperando a sua aprovação 🙂

Como funcionam as permissões assistidas do GitHub Copilot

O modo Assisted coloca um modelo de linguagem entre o agente e você, decidindo quais pedidos precisam do seu ok

São três tipos de pedido avaliados:

• rodar um comando
• acessar um caminho do sistema de arquivos
• abrir uma URL

Se o pedido é classificado como claramente seguro, ele segue automaticamente

Qualquer outro pedido cai na aprovação manual, do jeito que já funcionava

E por que isso importa? Porque no Copilot CLI as opções que já existiam ficam bem nos extremos

Segundo a documentação de permissões de ferramentas do CLI, o cenário é este:

• operações somente leitura (busca, leitura de arquivos, comandos de shell somente leitura) costumam ser permitidas automaticamente, sujeitas à política aplicável
• comandos destrutivos, edição de arquivos e acesso a URLs precisam de permissão, conforme as permissões existentes e o modo de permissão ativo
• --allow-all-tools dá acesso total às ferramentas disponíveis
• --allow-tool libera ferramentas específicas ou subcomandos sem pedir permissão, tipo --allow-tool='shell(git commit)'
• --deny-tool bloqueia uma ferramenta; segundo a documentação, regras de bloqueio sempre têm precedência sobre as de liberação, mesmo com todas as ferramentas liberadas ou com aprovação salva em permissions-config.json

Tem mais um detalhe que vale guardar: no modo de aprovação manual, o CLI permite autorizar uma ferramenta uma única vez ou pelo resto da sessão

Então, ao escolher entre "uma vez" ou "resto da sessão", pense no que essa ferramenta pode fazer durante toda a sessão, não só no comando que você está vendo na hora de aprovar

Ou seja, antes era aprovar tudo na mão, liberar uma ferramenta inteira ou liberar geral

O Assisted entra no meio disso, e a mesma documentação de permissões de ferramentas do CLI deixa o objetivo claro: reduzir a frequência dos pedidos de aprovação sem conceder permissões amplas (blanket permissions)

Pra entender como os pedidos são avaliados e quando a aprovação é exigida, o próprio GitHub aponta o documento oficial "Allowing safe commands to run without manual approval"

Como ativar o modo Assisted no CLI, no app e no VS Code

Cada produto tem o seu caminho, então não mistura os menus, beleza?

No Copilot CLI

Rode o comando abaixo e selecione assisted:

/permissions

A documentação do CLI também cita o slash command /permissions assisted dentro de uma sessão interativa

No app do GitHub Copilot

Abra o seletor de modo (mode picker), clique em Tool permissions e selecione Assisted

No VS Code

Abra o seletor de permissões (permissions picker) e selecione Assisted permissions

Um ponto importante: o anúncio não detalha versão mínima nem quais planos do Copilot têm acesso ao modo

Então, se a opção não aparecer pra você, não dá pra cravar o motivo só com o changelog

O que muda para empresas: controles de administrador

Administradores enterprise ganharam controle separado sobre o Allow All e sobre o Assisted, usando as configurações gerenciadas pela empresa (enterprise-managed settings)

Na prática, o admin pode:

• bloquear o Allow All e manter o Assisted disponível
• desativar o Assisted separadamente
• definir o modo de permissão padrão das novas sessões

O dev ainda pode escolher outro modo, desde que a política permita

E se o modo padrão estiver indisponível ou for proibido pela política, a sessão começa com aprovação manual

Isso é massa pra time que quer liberar agente sem abrir a porteira toda

Dá pra tirar o "libera geral" da mesa e ainda assim deixar o pessoal trabalhar sem aprovar comando por comando, com a aprovação manual como rede de segurança quando a configuração não bate com a política

Quem ganha com o recurso e qual é o limite

Quem mais ganha é quem usa agente no terminal ou no editor e já cansou de aprovar cada comando, mas não quer liberar tudo

Aquele meio-termo que faltava, sabe? 😀

Porém, o limite é bem claro: quem decide o que é "claramente seguro" é um modelo, e modelo erra

O changelog não informa taxa de acerto da classificação, então não trate o Assisted como garantia

Alguns cuidados práticos que fazem sentido aqui:

• ler o documento oficial "Allowing safe commands to run without manual approval" antes de confiar no modo
• rodar o agente em um ambiente isolado, ainda mais em projeto que importa (o blog já falou do sandbox local do GitHub Copilot)
• revisar os diffs antes de aceitar qualquer mudança
• ao autorizar uma ferramenta pelo resto da sessão, lembrar que ela segue valendo pro que vier depois, não só pro pedido atual

Nada disso vem como regra do produto, é bom senso de quem não quer descobrir o erro do modelo em produção

Se você ainda não usa a ferramenta e quer entender o que é o GitHub Copilot antes de mexer em permissão, o vídeo abaixo é uma introdução geral ao Copilot do canal Hora de Codar

Próximo passo: ligar o modo Assisted com segurança

Começa pequeno: ative o Assisted em um repositório de teste ou num ambiente isolado e observe o que passa direto e o que ainda pede aprovação

Antes de levar pro projeto principal, leia o "Allowing safe commands to run without manual approval" pra saber como os pedidos são avaliados

Se você administra um enterprise, vale sentar com o time e decidir duas coisas: qual será o modo padrão das novas sessões e se o Allow All fica bloqueado

Até o próximo post!

Quer aprender mais sobre inteligência artificial e programação na prática? Conheça o canal Hora de Codar no YouTube e acompanhe os próximos vídeos.