As permissões assistidas (assisted permissions) do GitHub Copilot CLI, do app do Copilot e do VS Code fazem com que um modelo revise cada solicitação do agente e aprove apenas as que considera seguras; o resto continua a pedir sua aprovação. Estão disponíveis de forma geral desde 26 de outubro.
Se você usa o agente do Copilot diariamente, conhece as duas opções que havia até agora. A aprovação manual é segura, mas o interrompe a cada poucos segundos. O modo allow-all (--allow-all, --yolo) elimina as interrupções e, com elas, seu controle sobre cada ação. As permissões assistidas são a proposta do GitHub para o meio termo.
O que são permissões assistidas no GitHub Copilot?
São um modo de permissões em que um modelo, e não você, toma a primeira decisão sobre as solicitações elegíveis. Segundo a documentação do GitHub, há três tipos de solicitações elegíveis:
- executar um comando
- acessar um caminho do sistema de arquivos
- abrir uma URL
Para cada uma, o modelo verifica se a ação é segura e se está dentro da autoridade que você deu ao Copilot para a tarefa. O resultado é um de dois:
- Tem certeza de que é segura: o Copilot a aprova e continua sem perguntá-lo.
- Não tem certeza: o Copilot o pergunta, exatamente como faria com aprovação manual.
Algumas coisas ficam fora da revisão. As solicitações que você já tinha permitidas são executadas sem perguntar e sem passar pelo modelo. As regras de negação e as restrições da empresa continuam se aplicando. As demais chamadas de ferramentas que as regras da empresa obrigam a aprovar, e as solicitações para contornar a sandbox local, não são revisadas pelo modelo: seguem o fluxo normal de permissões da sessão. Se a revisão não estiver disponível ou não conseguir avaliar uma solicitação, essa solicitação também volta ao fluxo normal.
O modelo que faz a revisão não é necessariamente o mesmo com o qual você está conversando. O Copilot escolhe o modelo revisor; se não estiver disponível, a revisão pode usar o modelo ativo de sua sessão. Se você usar seu próprio provedor de modelos, a revisão sempre usa o modelo ativo da sessão.
Permissões assistidas, aprovação manual ou --yolo?
| Modo | Revisão por modelo | Quando o pergunta | Supervisão |
|---|---|---|---|
| Aprovação manual | Não | Em cada ação que não esteja já permitida (aprovação única ou para toda a sessão) | Máxima |
| Permissões assistidas | Sim, em solicitações elegíveis | Apenas quando o modelo não tem certeza | Menos interrupções, sem permissão global |
Allow-all (--allow-all, --yolo, /permissions allow-all, /yolo) |
Não | Nunca | Nenhuma por ação |
A diferença prática: allow-all concede confiança antecipadamente para toda a sessão. As permissões assistidas a concedem solicitação por solicitação, de acordo com um julgamento sobre essa ação específica.
Como ativá-las no Copilot CLI, no app e no VS Code?
No Copilot CLI
Dentro de uma sessão interativa:
/permissions assistedas ativa apenas para a sessão atual/permissions manualvolta para aprovação manual/permissions showmostra o modo atual/permissionssem argumentos abre uma lista para escolher
Para que seja o modo padrão em todas as novas sessões interativas, adicione isto a ~/.copilot/settings.json:
{
"defaultPermissionMode": "assisted"
}
Mude para "manual" para voltar.
Em execuções não interativas (scripts, CI), use a flag ou a variável de ambiente:
copilot -p "Fix the failing tests" --assisted-approval
COPILOT_ASSISTED_APPROVAL=true
--assisted-approval é apenas para execuções não interativas: se você a usar para iniciar uma sessão interativa, o comando termina com um erro.
No app do GitHub Copilot
Abra o menu de modo, escolha Tool permissions e depois Assisted. Isso também a salva como padrão para novas sessões locais. Para alterar apenas a sessão atual, digite /permissions assisted na caixa de prompt.
No VS Code
Selecione Assisted permissions no seletor de permissões do chat. Segundo a documentação do VS Code, há três condições:
- A opção não está disponível em sessões com o harness Local.
- Você deve escolher isolamento Folder: as sessões em Worktree sempre usam Allow all.
- A primeira vez que você escolhe esse nível, um diálogo de aviso pede sua confirmação.
O nível com o qual as novas sessões iniciam é definido com a configuração chat.permissions.default.
O que acontece em modo autopilot e em CI?
Em modo autopilot e em execuções não interativas não há ninguém para perguntá-lo, então as solicitações que precisariam de sua aprovação são negadas. A explicação do modelo volta para o Copilot, para que o agente tente outro caminho em vez de ficar bloqueado.
Para automação, isto é o mais importante: com permissões assistidas, uma execução autônoma é fechada em negativo diante de qualquer coisa sobre a qual o modelo não tem certeza.
Como bloquear --yolo para todo o time?
Aqui a funcionalidade se torna uma ferramenta de governança. Os administradores de uma empresa podem usar as configurações gerenciadas (enterprise-managed settings) para controlar quais modos os desenvolvedores podem usar:
permissions.disableBypassPermissionsMode: "disable"bloqueia a aprovação incondicional (allow-all) sem desativar as permissões assistidaspermissions.disableAssistedPermissionsMode: truedesativa as permissões assistidaspermissions.defaultModedefine um modo padrão gerenciado para novas sessões, que tem prioridade sobre odefaultPermissionModede cada desenvolvedor
Os desenvolvedores podem mudar para qualquer outro modo que a política permita. Se o modo padrão configurado não estiver disponível ou for proibido, a sessão inicia com aprovação manual.
A primeira opção é a interessante. Até agora, um time que queria menos interrupções tinha que tolerar que seus desenvolvedores usassem --yolo. Agora um administrador pode tirar --yolo da mesa e deixar as permissões assistidas como a opção rápida.
Referência: Configuración administrada por la empresa - GitHub Enterprise Cloud Docs
É seguro usá-lo sem sandbox?
Não por si só, e o GitHub o diz sem rodeios. Sua documentação avisa que o modelo pode se enganar e aprovar ações perigosas ou indesejadas, e que a funcionalidade não substitui o sandboxing nem as restrições de acesso. Menos interrupções não o tiram da responsabilidade sobre o que o Copilot faz.
Antes de colocar isso em um pipeline, há dois detalhes da CLI que convém revisar:
- As flags não se anulam mutuamente.
--assisted-approvalanula--allow-all-tools, mas--allow-all-pathse--allow-all-urlscontinuam se aplicando. Se você combinar as permissões assistidas com--allow-allou--yolo, o acesso a caminhos e URLs pode ficar sem restrições. - Pode falhar silenciosamente. Se as permissões assistidas não puderem ser ativadas (por exemplo, porque a configuração da empresa as bloqueia), a CLI escreve um aviso na saída de erro padrão e qualquer
--allow-all-toolsque você tenha passado continua se aplicando. Em execuções automatizadas, revise stderr procurando por esse aviso.
Mais um para ambientes empresariais: na CLI, as regras ask da empresa para comandos de shell, leituras de arquivos, escritas de arquivos e URLs podem ser consideradas satisfeitas com a aprovação do modelo. Uma regra ask não garante mais que uma pessoa veja a solicitação.
A configuração sensata é usar permissões assistidas dentro de um ambiente isolado, não em lugar de um. Explicamos como ativar a sandbox local do Copilot aqui: Sandbox local do GitHub Copilot: como ativá-la na CLI, no app e no VS Code e o que ela não bloqueia.
Em quais planos do Copilot está disponível?
No momento da publicação desta nota, nem o changelog nem a documentação do GitHub indicavam em quais planos do Copilot as permissões assistidas estão incluídas.
E você? Que ação você nunca deixaria que um modelo aprovasse sem o perguntá-lo?
- Aprovação manual
- Permissões assistidas
- Allow-all / --yolo
- Prefiro outra opção (conte-nos qual)
Comente abaixo ou, se este artigo o chegou por e-mail, responda diretamente ao email: sua resposta é publicada aqui.
Relacionado: GitHub Copilot Aposta na Autonomia — E Constrói o Guardrail para Contê-la