Resposta rápida
Desde 6 de novembro de 2026, administradores podem usar as APIs REST e GraphQL do GitHub para gerenciar parte das configurações do Copilot code review. O enterprise pode habilitar, desabilitar ou delegar a decisão; a organização controla habilitação, esforço padrão e runner; o repositório escolhe esforço e o uso de instruções personalizadas e ferramentas MCP.
Antes de automatizar, aplique a política no nível mais alto, confirme qual tipo de credencial o endpoint aceita, limite o esforço e a cobrança, teste em um repositório piloto e registre o estado anterior. Máximo de esforço, billing e aprovações continuam fora dessa API e precisam ser administrados pelas configurações próprias do GitHub.
O que mudou em 6 de novembro
O GitHub ampliou a API de revisão do Copilot. Além de solicitar uma revisão e informar o esforço desejado, integrações agora podem ler e atualizar configurações administrativas de acordo com a função de quem chama. A resposta também pode indicar esforço usado e atribuir comentários a skills, servidores MCP e instruções personalizadas.
O anúncio também trouxe uma visão de revisão mais compacta, exposição de créditos de IA nas sessões do agente, uma tentativa automática adicional em revisões que falham ou expiram e suporte a lista de bypass nas regras de revisão automática. Essas melhorias não mudam a necessidade de validar permissões, orçamento e controles humanos de merge.
O que cada nível pode controlar
A hierarquia é deliberada. Uma decisão administrada pelo enterprise não pode ser substituída pela organização. A organização só pode habilitar ou desabilitar quando o enterprise delega essa escolha. O repositório recebe o resultado das políticas superiores e controla apenas os detalhes locais expostos pela API.
- Enterprise: defina se Copilot code review fica habilitado, desabilitado ou sob decisão das organizações.
- Organização: quando permitido, defina habilitação, esforço padrão e configuração do runner usado pelas funções agentivas.
- Repositório: escolha o esforço de revisão e se instruções personalizadas e ferramentas MCP podem ser usadas.
- Interface administrativa: mantenha máximo de esforço, cobrança e aprovações, porque esses controles não estão disponíveis nessa API.
Escolha a credencial antes de escrever a automação
Os endpoints de enterprise e organização, inclusive o endpoint de runner da organização, não aceitam GitHub Apps nem personal access tokens fine-grained. Para esses níveis, siga exatamente o tipo de autenticação e os privilégios documentados no endpoint escolhido; não presuma que a credencial usada no repositório funcionará acima dele.
Nos endpoints de repositório, GitHub Apps e tokens fine-grained são aceitos. A leitura exige a permissão Administration: read e a atualização exige Administration: write. Um token classic precisa pertencer a um administrador do repositório. Prefira uma credencial curta, restrita ao menor conjunto de repositórios e armazenada em cofre; nunca imprima o header Authorization nos logs.
- Identifique primeiro se a alteração pertence ao enterprise, à organização ou ao repositório.
- Abra a documentação do endpoint e confirme tipos de token, função administrativa e permissão exigida.
- Separe credenciais de leitura e escrita quando o pipeline permitir.
- Faça uma leitura inicial e salve somente os valores não secretos necessários para reversão.
- Recuse a execução se a resposta apontar política superior, nível de esforço indisponível ou repositório fora do escopo.
Rollout seguro em cinco etapas
Não comece por todos os repositórios. Escolha um projeto ativo, com equipe responsável e pull requests representativos. Leia a configuração atual, aplique uma mudança pequena, peça uma revisão em um pull request de teste e compare a resposta da API com a interface do GitHub.
Depois da validação, amplie por lotes e mantenha a configuração desejada como dado versionado. Uma automação idempotente deve comparar antes de escrever, tratar 403 como possível bloqueio de política ou permissão e parar diante de valor desconhecido. Não tente corrigir a hierarquia repetindo a mesma chamada.
- Leia enterprise, organização e repositório nessa ordem e registre a política efetiva.
- Escolha um repositório piloto e um pull request sem segredo ou dado sensível.
- Aplique somente esforço, instruções ou MCP que a política permite.
- Solicite uma revisão e confira esforço, atribuições, sessão do agente e créditos consumidos.
- Revise o audit log, documente o resultado e só então amplie para o próximo lote.
Lite, Balanced ou Max: custo e precedência
O GitHub descreve Lite como revisão padrão, Balanced como análise mais profunda de lógica complexa, segurança e mudanças entre serviços, e Max como a revisão de maior esforço. Balanced é o padrão embutido. As estimativas oficiais médias por revisão são US$ 0,25 no Lite, US$ 1,50 no Balanced e US$ 10 no Max, com faixas que variam conforme a revisão e sem incluir minutos do GitHub Actions.
O esforço efetivo não vem de um único campo. A precedência documentada começa no esforço solicitado explicitamente, passa pelo esforço anterior do pull request, pela escolha de quem pediu a revisão, pelo repositório e pela organização, e termina no padrão Balanced. Defina o máximo permitido na política administrativa e não confunda o valor padrão da API com um teto de custo.
MCP e skills ampliam contexto e risco
Copilot code review pode usar skills em .github/skills e servidores MCP configurados no repositório. Quando uma fonte participa de um comentário, a atribuição pode aparecer no próprio resultado, e a sessão vinculada permite verificar servidores e ferramentas chamados. Isso ajuda a provar de onde veio o contexto usado na revisão.
A configuração MCP do repositório é compartilhada com o Copilot cloud agent, e as ferramentas podem ser chamadas autonomamente sem uma aprovação por uso. O GitHub e o Playwright MCP ficam habilitados por padrão. O recurso aceita ferramentas MCP, mas não recursos ou prompts, e servidores remotos com OAuth não são compatíveis nesse fluxo. Desabilite MCP para code review quando a revisão não precisa desse acesso e trate qualquer segredo como credencial de agente.
Como validar se a configuração funcionou
Uma resposta 200 da atualização prova apenas que a operação foi aceita. Releia a configuração, abra o repositório no GitHub e solicite uma revisão manual ou automática. No resultado, confirme o esforço realmente usado, a atribuição do Copilot e, quando houver, as referências a instruções, skills e MCP.
Copilot envia a revisão como comentário por padrão; isso não equivale a aprovação humana. Aprovações do Copilot não contam para requisitos de merge até que a política correspondente seja habilitada. Se Actions estiver indisponível, a revisão ainda pode ser gerada, mas perde funções agentivas adicionais. Consulte o GitHub Status quando vários repositórios falharem ao mesmo tempo.
- Leia novamente o endpoint alterado e compare os valores desejados e efetivos.
- Verifique a configuração correspondente na interface administrativa do GitHub.
- Solicite revisão em um pull request de teste e confira comentário, esforço e atribuições.
- Abra a sessão do agente e verifique créditos, MCP e ferramentas chamadas.
- Confirme que regras de proteção e revisão humana continuam exigindo o que a equipe definiu.
Auditoria, reversão e métricas
O audit log inclui eventos para mudanças nas configurações de revisão do Copilot na organização e no repositório. Registre ator, horário, operação e valores anteriores, mas não tokens. Para reverter, aplique novamente o estado previamente lido e valide o resultado no mesmo repositório piloto.
A API de métricas de uso também passou a detalhar comentários avaliados e tratados, severidade, nível de revisão e personalização. Use addressed rate e revisões humanas posteriores como sinais operacionais, não como prova isolada de qualidade. Um comentário aceito pode estar errado, e ausência de pedido humano de mudança não demonstra que a revisão encontrou todos os problemas.
Limitações e próxima ação útil
Este guia foi verificado em 9 de novembro de 2026. A API administra apenas parte das configurações: máximo de esforço, billing e aprovações continuam fora dela. Disponibilidade depende do plano, das políticas superiores, das permissões e dos créditos. Copilot não substitui revisão humana, testes, code scanning, secret scanning nem proteção de branch.
A próxima ação é escolher um repositório piloto, ler a configuração nos três níveis e anotar o estado anterior. Aplique o esforço Lite ou Balanced com MCP desativado, solicite uma revisão, confira atribuição, custo, audit log e regras de merge e então decida se skills ou MCP realmente acrescentam contexto antes de ampliar o rollout.
Faça o próximo teste
Fontes consultadas
Os links abaixo servem para conferir conceitos, orientações oficiais e o critério editorial usado neste conteúdo.
- Copilot code review: API management and review overview updatesGitHub Changelog
- Configuring code review by GitHub CopilotGitHub Docs
- GitHub Copilot code reviewGitHub Docs
- Using GitHub Copilot code reviewGitHub Docs
- Configure MCP servers for your repositoryGitHub Docs
- Audit log events for your organizationGitHub Docs
- Usage metrics API adds code review details and addressed rateGitHub Changelog
- GitHub StatusGitHub