Copilot CLI: como instalar, usar no terminal e avaliar os custos

Como instalar o GitHub Copilot CLI e fazer login

Use o pacote npm estável do GitHub, @github/copilot, com Node.js 22 ou superior. No Windows, o GitHub também exige PowerShell v6 ou superior. Se o acesso ao Copilot vem da sua organização, o administrador precisa habilitar a política do Copilot CLI. Requisitos de instalação.

Execute no terminal:

npm install -g @github/copilot

Se o seu ~/.npmrc define ignore-scripts=true, o GitHub oferece esta alternativa: npm_config_ignore_scripts=false npm install -g @github/copilot. Os outros instaladores documentados são winget install GitHub.Copilot no Windows, brew install --cask copilot-cli no macOS ou Linux e curl -fsSL https://gh.io/copilot-install | bash no macOS ou Linux. O requisito de Node se aplica à instalação via npm. Comandos de instalação do GitHub.

Entre no diretório do repositório em que você quer trabalhar e execute copilot. Confirme que confia na pasta, apenas para a sessão atual ou também para as próximas. Se ainda não estiver autenticado, digite /login dentro do Copilot quando solicitado. Primeira execução.

Escolha GitHub.com ou o hostname do seu GitHub Enterprise Cloud com residência de dados. Em um computador local com interface gráfica, escolha a autenticação pelo navegador; em ambientes remotos ou sem interface gráfica, o fluxo com código de dispositivo costuma aparecer primeiro. Conclua a autorização no navegador, autorize as organizações relevantes caso usem SAML SSO e aprove o aplicativo GitHub Copilot CLI. Volte ao terminal depois de concluir o login. Você também pode iniciar a autenticação pelo shell com copilot login. Instruções de autenticação.

Se a CLI selecionar a conta errada, verifique as variáveis COPILOT_GITHUB_TOKEN, GH_TOKEN e GITHUB_TOKEN: tokens exportados explicitamente têm prioridade sobre o login salvo. Para automação, o GitHub aceita um token de acesso pessoal com permissões granulares, vinculado a uma conta pessoal, com a permissão de conta Copilot Requests. Tokens de acesso pessoal clássicos não são aceitos. Autenticação e prioridade dos tokens.

Primeiras tarefas: entender o código, corrigir testes e abrir um PR

Comece com uma pergunta, passe para uma alteração que você consiga verificar e depois abra um pull request. Pense na CLI como um desenvolvedor ao seu lado: ela pode inspecionar o projeto e usar ferramentas, enquanto você decide quais ações autorizar.

A tabela diferencia comandos no shell de entradas em uma sessão interativa de copilot. Todos os comandos e prompts abaixo aparecem na documentação do GitHub. Cada interação com um modelo consome créditos de IA; o GitHub não publica um custo fixo em créditos para essas tarefas. Como funciona a cobrança da CLI.

Entenda o repositório antes de alterar o código

Ao entrar em um projeto desconhecido, um desenvolvedor pode começar pelo comando de explicação da tabela. O exemplo do GitHub seleciona Claude Haiku 4.5; -p envia um único prompt e encerra a execução, -s suprime a saída adicional e --model escolhe o modelo. Se esse modelo não estiver disponível no seu plano ou pelas políticas de acesso, abra uma sessão interativa e use /model para escolher entre as opções disponíveis. Contas Free e Student usam a seleção Auto. Exemplo de uso programático, acesso aos modelos.

Use a explicação para localizar os pontos de entrada e a configuração dos testes, depois confira esses arquivos por conta própria. Você ganha um mapa inicial concreto, que pode questionar, em vez de percorrer diretórios sem uma direção clara.

Corrija um teste com um resultado verificável

Diante de um teste que falha, o responsável pelo projeto pode executar o comando de testes do próprio repositório, fornecer a saída da falha ao Copilot e usar o prompt interativo da tabela. O GitHub apresenta esse texto no fluxo de desenvolvimento orientado a testes, depois da criação e revisão de testes que falham. Para uma falha já existente, forneça o contexto que falta: qual teste falha e qual comportamento deve ser preservado. Revise o diff e execute novamente o teste relevante antes de aceitar a alteração. Fluxo de testes do GitHub.

Para um teste que já falha na CI — as verificações automatizadas vinculadas a um pull request existente —, o GitHub oferece /pr fix ci focus on test failures. O comando investiga logs, aplica correções e pode enviar alterações ao repositório remoto. Por isso, trate esse fluxo separadamente do reparo de um teste local. É necessário que a branch atual já tenha um PR. Como corrigir falhas na CI.

Abra o pull request depois de revisar a alteração

Um fundador que precisa entregar uma correção pequena pode usar /pr create na branch de trabalho depois de revisar a alteração e fazer o commit. Você precisa estar em um repositório Git hospedado no GitHub. O Copilot envia os commits locais e cria o PR, seguindo o template de pull request do repositório para o título e a descrição. Se a branch já tiver um PR, o comando o atualiza. Como criar um pull request.

Assim, a entrega fica pronta para revisão dentro do fluxo de trabalho que a equipe já usa no GitHub. A responsabilidade pelo conteúdo da branch continua sendo sua.

O que o Copilot pede para aprovar antes de executar comandos?

Confiar na pasta e autorizar uma ferramenta são decisões separadas. Quando uma ação exige aprovação, você pode permiti-la uma vez, autorizar a ferramenta durante a sessão em andamento ou recusar e dar feedback. A aprovação da sessão abrange a ferramenta e suas opções. Solicitações de aprovação.

Operações somente de leitura podem executar automaticamente; ações potencialmente destrutivas, gravações e acesso a URLs exigem aprovação, a menos que ela já tenha sido concedida. Algumas solicitações permitem salvar a aprovação para o repositório ou diretório. A autorização permanente de domínios de URL vale entre sessões. Permissões salvas.

Este é o exemplo do GitHub para permissões predefinidas:

copilot --allow-tool='shell(git:*)' --deny-tool='shell(git push)'

Ele permite comandos Git, mas bloqueia pushes. Regras de bloqueio têm prioridade sobre regras de permissão e aprovações salvas. /reset-allowed-tools limpa as aprovações da sessão e as autorizações de ferramentas salvas para o local atual, restaurando as permissões definidas na inicialização. Regras de permissão e bloqueio.

--allow-all-tools autoriza todas as ferramentas disponíveis. --allow-all ou --yolo também autoriza todos os caminhos e URLs. O GitHub recomenda usar permissões amplas em um ambiente isolado. Nas primeiras tarefas, mantenha o fluxo normal de aprovação. Opções de permissões amplas.

Quais planos incluem a CLI e como funciona a cobrança?

Todos os planos do Copilot incluem a CLI: Free, Student, Pro, Pro+, Max, Business e Enterprise. Você não precisa contratar uma assinatura separada da CLI além da licença do Copilot que já tem. Estes são os preços mensais e as cotas atuais na página de planos do GitHub. Planos do Copilot.

A parcela flex é variável, então os totais atuais não garantem uma capacidade permanente. Um crédito de IA equivale a $0.01 USD. Os preços do modelo selecionado e os tokens de entrada, saída e em cache determinam o consumo. O chat e a CLI usam a mesma cota. As sugestões de conclusão de código e de próxima edição nos planos pagos continuam ilimitadas e não consomem créditos de IA. Cobrança para contas individuais.

Para quem já assina o Pro, a assinatura continua em $10 por mês; o trabalho dos modelos no terminal disputa a cota atual de 1,500 créditos. Essa é a conta que vale fazer: experimente o acesso que você já tem e avalie se a cota compartilhada atende ao seu trabalho. Usuários individuais de planos pagos podem definir um orçamento para uso adicional, mudar de plano ou esperar a renovação mensal da cota. A tabela pública de preços não oferece a compra de créditos adicionais no Free. Cotas individuais, restrições de compra no plano Free.

Nos planos Business e Enterprise, os créditos são compartilhados no nível da entidade de faturamento. O uso adicional pago vem habilitado por padrão e pode ser desativado pelos administradores. Um orçamento por usuário ou um limite de gastos da empresa pode interromper o acesso mesmo quando ainda resta outra cota. O GitHub recomenda CLI 1.0.48 ou superior para exibir corretamente a cobrança e o uso. Cobrança para organizações.

Consulte /usage depois de uma tarefa para ver os créditos da sessão e o uso de tokens por modelo. Em uma sessão interativa, você pode usar /limits set max-ai-credits NUMBER, substituindo NUMBER pela cota desejada. O mínimo é de 30 créditos. O recurso está em prévia pública e funciona como um limite flexível: uma resposta em andamento termina e pode ultrapassá-lo ligeiramente. Exibição de uso, limites da sessão.

Quais modelos o Copilot CLI pode usar?

Use /model dentro do Copilot para ver suas opções ou --model ao executá-lo pelo shell. A tabela atual de clientes do GitHub lista estes modelos como compatíveis com a CLI; seu plano e as políticas do administrador podem restringir o acesso. Modelos compatíveis.

A tabela separada do GitHub para o modo Auto da CLI também inclui GPT-6.1 Sol. Free e Student usam apenas Auto. A disponibilidade muda, então consulte o seletor para ver as opções atuais da sua conta. Auto e disponibilidade por plano.

Como adicionar instruções do projeto e ferramentas MCP

Defina as regras de trabalho do repositório antes de pedir alterações recorrentes. Instruções personalizadas são arquivos Markdown que o Copilot inclui no contexto. Coloque os comandos de build, os comandos de testes e as convenções válidas para todo o projeto em .github/copilot-instructions.md. Use .github/instructions/**/*.instructions.md com padrões applyTo para regras que se aplicam a caminhos específicos. Instruções personalizadas.

A CLI também encontra AGENTS.md, CLAUDE.md, .claude/CLAUDE.md e GEMINI.md. Preferências do usuário válidas entre projetos podem ficar em ~/.copilot/copilot-instructions.md ou ~/.copilot/instructions/**/*.instructions.md. As instruções aplicáveis são combinadas; o GitHub não define uma ordem geral de prioridade entre elas. Mantenha os arquivos coerentes entre si e use /instructions para inspecionar ou desativar os que forem encontrados. Descoberta e combinação de instruções.

MCP, Model Context Protocol, conecta um agente a ferramentas e dados externos. Pense nele como uma conexão de serviço adicionada ao ambiente de trabalho. O servidor MCP do GitHub já vem integrado. Para adicionar outro servidor, use /mcp add, navegue entre os campos com Tab e salve com Ctrl+S. Servidores locais ou stdio executam um processo; servidores HTTP se conectam a um endpoint remoto. O formato legado SSE também é compatível. Como adicionar servidores MCP.

O exemplo do GitHub para o terminal é copilot mcp add --transport http sentry https://mcp.sentry.dev/mcp. A configuração do usuário fica em ~/.copilot/mcp-config.json; a configuração do projeto pode usar .mcp.json ou .github/mcp.json. O guia específico de MCP informa que as políticas configuradas de registro e lista de permissão da organização se aplicam à CLI. Exemplo no terminal, configuração e políticas.

Quando usar a CLI, o IDE ou outro agente?

Minha recomendação: comece pelo Copilot CLI quando a tarefa já acontece no terminal e você tem uma licença do Copilot. Escolha a extensão do IDE quando quiser trabalhar junto ao arquivo que está editando, inspecionar alterações visualmente e continuar no editor. Nossa comparação entre Cursor e GitHub Copilot ajuda nessa decisão.

Além das primeiras tarefas, há outras possibilidades úteis:

• Um responsável pelo projeto preparando uma revisão pode pedir uma revisão de código da branch de trabalho, investigar os pontos levantados e encaminhar o diff a um revisor humano. O resultado é uma lista focada de verificações, desde que os pontos levantados se confirmem. O GitHub documenta fluxos de revisão local. Orientações de revisão.
• Um desenvolvedor respondendo a comentários de um PR pode usar /pr fix feedback, inspecionar as alterações propostas e aprovar os pushes resultantes. Isso mantém as mudanças solicitadas e a discussão no mesmo lugar. O comando pode responder aos tópicos de revisão tratados e marcá-los como resolvidos, então confira o escopo antes de aprovar. Fluxo de feedback.

Considere outro agente de terminal quando precisar de uma cota de assinatura diferente, de outra configuração de provedores ou de mais controle sobre o próprio agente. Nossa comparação de alternativas ao Claude Code e custos no terminal ajuda nessa decisão de compra. Antes, verifique se os modelos do próprio Copilot atendem à sua necessidade: o GitHub também documenta o uso de um provedor próprio, incluindo modelos locais compatíveis. Esse caminho exige configuração separada do provedor, chamadas de ferramentas e streaming; é uma configuração diferente daquela que usa sua cota do Copilot. Como usar um modelo próprio.

O que uma equipe pequena pode criar com isso?

Um pacote de integração de novos desenvolvedores ao repositório é a oportunidade inicial mais forte. Desenvolvedores buscam “how to understand a new codebase” e “ai tool to understand codebase.” Uma equipe pode vender a líderes de engenharia um pacote mantido com notas de arquitetura, instruções de build verificadas e tarefas de integração com escopo definido. A menor versão útil cobriria o repositório do cliente e demonstraria o fluxo de entender o código, testar e abrir um PR. O desafio: prompts genéricos são fáceis de copiar; o comprador pagaria pelo conhecimento do projeto mantido e atualizado.

Um fluxo de preparação para revisão é outra possibilidade. Buscas por “ai code review tools” e “ai powered code review platform” apontam para essa demanda. Uma equipe pode combinar instruções do projeto e contexto de issues conectadas para produzir um pacote de revisão com alterações, evidências de testes e perguntas em aberto. O comprador seria um líder de equipe que quer padronizar as entregas para revisão. O desafio: os pontos levantados pelo agente precisam de validação, e o fluxo deve justificar seu espaço ao lado dos recursos de revisão que o GitHub já oferece. São possibilidades de produto, sem resultados demonstrados.

Limitações para considerar no seu fluxo de trabalho

A CLI pode produzir uma alteração que parece correta, mas está errada. As orientações de uso responsável do GitHub dizem que o conteúdo gerado pode ser impreciso ou incompleto e recomendam verificar o código e os comandos da CLI. Executar os testes relevantes com sucesso e revisar o diff continuam fazendo parte do trabalho. Uso responsável.

Confiar em uma pasta não garante isolamento. O GitHub descreve o escopo das permissões de diretório como heurístico e não garante a proteção de todos os arquivos fora dos diretórios confiáveis. Comece no repositório em que pretende trabalhar. Para restrições mais rígidas, /sandbox enable ativa o isolamento local das ferramentas; os sandboxes locais e na nuvem do GitHub estão em prévia pública. Confiança em diretórios e isolamento.

Limites de acesso e de gastos continuam valendo. Um modelo listado na documentação pode estar indisponível no seu plano ou desativado por uma política. A CLI compartilha créditos com outros usos do Copilot, e o limite de sessão em prévia pode ser ultrapassado ligeiramente. Orçamentos da organização podem interromper o uso sem uma troca automática para um modelo mais barato. Acesso aos modelos, limites da sessão, comportamento dos orçamentos.

Na próxima sessão de trabalho, escolha um teste que esteja realmente falhando em uma branch que você possa revisar. Peça uma explicação do código relevante, aprove as solicitações de ferramentas para a correção, execute o teste novamente, consulte /usage e abra o PR. Assim, você consegue avaliar com dados concretos se o fluxo funciona para você e quanto consome.

Se você quer um fluxo de trabalho para o repositório que incorpore as verificações e ferramentas conectadas da sua equipe, criamos automações com IA.