GitHub Copilot CLI: agentes, MCP e automação no terminal
O GitHub Copilot CLI leva o Copilot diretamente para o terminal e transforma o shell em um ambiente interativo de geração, análise e automação de código. Neste artigo, apresento uma visão técnica sobre a ferramenta, desde a instalação até agentes, servidores MCP, skills e delegação de tarefas.
Nos últimos anos, tenho acompanhado de perto a evolução das ferramentas de assistência por IA voltadas ao desenvolvimento de software. Nesse cenário, a chegada do Copilot ao terminal representa um avanço significativo, porque amplia a autonomia do desenvolvedor no fluxo diário de trabalho.
O que é o GitHub Copilot CLI
O GitHub Copilot CLI é uma extensão do ecossistema Copilot que permite interagir com agentes de IA a partir da linha de comando. Em vez de limitar a experiência ao editor, o Copilot passa a atuar no contexto do sistema operacional, do repositório e dos comandos executados.
Com essa abordagem, torna-se possível realizar várias tarefas sem sair do terminal:
- Gerar arquivos e trechos de código sob demanda.
- Refatorar código em múltiplos arquivos.
- Analisar falhas de build e erros de execução.
- Automatizar tarefas repetitivas.
- Delegar atividades completas para execução assíncrona.
Segundo a documentação oficial do GitHub, a ferramenta está disponível em todos os planos do Copilot. Além disso, ela roda no Linux, no macOS e no Windows, tanto pelo PowerShell quanto pelo WSL.
Modo interativo e modo programático
O GitHub Copilot CLI trabalha de duas formas. No modo interativo, você inicia uma sessão com o comando copilot e conversa com o agente, dando feedback e ajustando a direção a cada passo.
Já no modo programático, você passa o prompt direto na linha de comando com a opção -p ou --prompt. Assim, o Copilot executa a tarefa e encerra, o que facilita o uso em scripts e rotinas automatizadas.
# Executa um prompt único, liberando apenas comandos do Git
copilot -p "Show this week's commits and summarize them" --allow-tool='shell(git)'
Inclusive, o modo interativo oferece um modo de planejamento, acionado com Shift+Tab. Nele, o agente monta um plano estruturado de implementação antes de escrever qualquer linha de código.
Como instalar o GitHub Copilot CLI
O processo de instalação é simples e multiplataforma. No macOS e no Linux, a instalação pode usar o Homebrew, o npm ou um script oficial, enquanto no Windows o caminho mais direto é o WinGet.
# npm (todas as plataformas, requer Node.js 22 ou superior)
npm install -g @github/copilot
# Homebrew (macOS e Linux)
brew install --cask copilot-cli
# WinGet (Windows)
winget install GitHub.Copilot
# Script de instalação (macOS e Linux)
curl -fsSL https://gh.io/copilot-install | bash
Para usar a ferramenta, você precisa de uma assinatura ativa do Copilot. No Windows, a documentação também pede o PowerShell na versão 6 ou superior.
Após a instalação, a inicialização ocorre diretamente pelo terminal, a partir da pasta do projeto.
copilot
Autenticação e pastas confiáveis
No primeiro uso, o GitHub Copilot CLI pede autenticação com uma conta GitHub válida por meio do comando /login. Durante a sessão, a interface mostra a conta ativa e os servidores MCP configurados, o que garante transparência sobre os recursos disponíveis.
Como alternativa, a ferramenta aceita um token de acesso pessoal refinado com a permissão Copilot Requests. Nesse caso, basta exportá-lo em uma das variáveis COPILOT_GITHUB_TOKEN, GH_TOKEN ou GITHUB_TOKEN, que o CLI verifica nessa ordem.
Além disso, o Copilot pergunta se você confia na pasta em que a sessão começou. Por isso, a recomendação oficial é iniciar a ferramenta apenas em diretórios confiáveis e evitar a pasta pessoal ou locais com dados sensíveis.
Interação por comandos e agentes
O GitHub Copilot CLI adota um modelo de interação centrado em slash commands. Esses comandos funcionam como instruções semânticas que orientam o comportamento do agente durante a sessão.
Além deles, dois atalhos aceleram bastante o trabalho. Primeiro, o @ seguido de um caminho relativo adiciona um arquivo específico ao prompt.
Em seguida, o ! no início da linha executa um comando de shell diretamente, sem nenhuma chamada ao modelo. Assim, você roda um !dotnet test sem sair da sessão nem gastar requisições.
Explain the validation rules in @src/Orders/OrderValidator.cs
!dotnet test
Agentes personalizados no GitHub Copilot CLI
O comando /agent exibe e seleciona os agentes personalizados configurados para o projeto atual. Essa funcionalidade é especialmente útil quando o time usa vários agentes especializados, como agentes de acessibilidade, segurança ou revisão de estilo.
Cada agente atua com um propósito bem definido, o que divide responsabilidades e torna as interações mais previsíveis. Na prática, um agente é um arquivo Markdown, chamado de perfil de agente, que define a especialidade, as ferramentas permitidas e as instruções.
Segundo a documentação, esses perfis podem ficar em três níveis:
- No repositório, dentro da pasta
.github/agents. - No usuário, dentro da pasta
~/.copilot/agents. - Na organização ou na empresa, na pasta
agentsdo repositório.github-private.
Por outro lado, você nem sempre precisa escolher o agente manualmente. De fato, o Copilot consegue inferir qual agente usar a partir do próprio prompt.
Seleção de modelos de linguagem
Uma das características mais relevantes do GitHub Copilot CLI é a possibilidade de alternar entre modelos de linguagem com o comando /model. Esse recurso permite selecionar modelos de diferentes provedores conforme o tipo de tarefa.
Por exemplo, modelos mais robustos servem para análises profundas ou refatorações complexas. Enquanto isso, modelos mais rápidos atendem bem a tarefas pontuais, como gerar um teste ou explicar um erro.
O modelo ativo fica visível na própria interface, o que facilita o controle do contexto durante a sessão. Também é possível definir o modelo já na inicialização, com a opção --model.
Vale lembrar que o consumo de créditos varia conforme o modelo escolhido. Por isso, o comando /usage ajuda a acompanhar quanto cada sessão está custando.
MCP no GitHub Copilot CLI
O suporte ao Model Context Protocol (MCP) é um dos pilares da extensibilidade do GitHub Copilot CLI. Com o comando /mcp, você consegue visualizar, adicionar, remover e gerenciar servidores MCP.
Esses servidores fornecem contexto adicional e capacidades especializadas ao Copilot, como ferramentas de testes, automação de navegadores ou serviços internos. Se o protocolo ainda é novidade para você, o artigo O que é MCP explica os fundamentos.
O CLI já inclui um servidor MCP nativo do GitHub. Com ele, o agente busca pull requests, lê issues e trabalha com workflows sem nenhuma configuração extra.
Adicionando servidores externos
Além do servidor nativo, você pode integrar servidores externos, como o MCP do Playwright para automação de navegadores. A configuração fica no arquivo ~/.copilot/mcp-config.json, que pode ser editado manualmente ou preenchido pelo comando /mcp add.
{
"mcpServers": {
"playwright": {
"command": "npx",
"args": ["-y", "@playwright/mcp@latest"]
}
}
}
Também é possível registrar um servidor remoto direto no terminal, com o comando copilot mcp add --transport http SERVER-NAME URL. Dessa forma, servidores corporativos hospedados ficam disponíveis em todas as sessões.
Essa arquitetura baseada em protocolo aberto favorece a interoperabilidade entre ferramentas. Ou seja, o mesmo servidor que você usa no VS Code tende a funcionar no terminal sem adaptações.
Delegação de tarefas em segundo plano
Um dos recursos mais avançados da ferramenta é o comando /delegate. Com ele, posso entregar uma tarefa completa ao Copilot, como implementar uma funcionalidade ou corrigir um bug, enquanto continuo trabalhando localmente.
Nesse caso, quem executa a tarefa é o agente de código do Copilot, de forma assíncrona e fora da sua máquina. Ao final, ele envia as alterações para uma nova branch e abre um pull request em rascunho para revisão.
/delegate Add input validation to the CreateOrder endpoint and cover it with unit tests
Esse modelo de execução paralela aproxima o GitHub Copilot CLI de um verdadeiro colaborador virtual no time. Afinal, a revisão do pull request continua com você, e nada entra na branch principal sem aprovação.
Permissões e modos avançados do GitHub Copilot CLI
Por padrão, o GitHub Copilot CLI pede aprovação sempre que vai usar uma ferramenta que modifica ou executa arquivos. Nessa hora, você pode aprovar só aquele comando, aprovar para toda a sessão ou recusar e redirecionar o agente.
Para quem prefere um fluxo mais fluido, existe o modo de permissões amplas, ativado pela opção --allow-all ou --allow-all-tools. Esse modo autoriza o agente a criar arquivos, editar código, executar comandos do Git e rodar comandos de shell sem confirmação.
Trata-se de um recurso poderoso, que deve ser usado com responsabilidade, especialmente em ambientes produtivos. Por isso, a documentação o classifica como de alto risco.
Permissões granulares
Felizmente, dá para liberar apenas o necessário com a opção --allow-tool. Por exemplo, --allow-tool='shell(git)' libera os comandos do Git, enquanto --allow-tool='write' libera a edição de arquivos.
Já a opção --deny-tool bloqueia ferramentas específicas e tem precedência sobre as liberações. Assim, você combina liberdade e segurança em uma única linha.
# Libera tudo, exceto a remoção de arquivos
copilot --allow-all-tools --deny-tool='shell(rm)'
Além disso, a ferramenta oferece sandbox local com /sandbox enable, que restringe o acesso ao sistema de arquivos. Para isolamento total, a opção --cloud executa a sessão em um ambiente remoto.
Executando um agente específico
Também é possível executar um agente específico diretamente na inicialização, com a opção --agent. Combinada a um prompt, ela transforma uma auditoria inteira em um único comando.
copilot --agent security -p "Run a full security audit of this repository"
Nesse exemplo, o Copilot executa uma auditoria de segurança completa usando o agente configurado para essa finalidade. Na prática, esse formato encaixa bem em rotinas agendadas ou em pipelines de integração contínua.
Compartilhamento de sessões
O comando /share exporta a sessão atual como um arquivo Markdown ou como um gist do GitHub. Esse recurso é útil para documentar fluxos complexos, revisar soluções em conjunto ou demonstrar um resultado para outros membros da equipe.
Para gerar o gist, o token de autenticação precisa ter o escopo adequado, o gist scope. Caso contrário, a exportação para arquivo local continua disponível.
Skills e especialização de fluxos
O comando /skills lista e gerencia as skills configuradas para o projeto. Skills representam capacidades especializadas, como pipelines de deploy, auditorias ou rotinas de validação.
Segundo o GitHub, uma skill é uma pasta com instruções, scripts e recursos que o Copilot carrega quando a tarefa pede. Por isso, o agente recebe apenas o contexto necessário, o que reduz ruído e aumenta a precisão das respostas.
As skills do projeto ficam em pastas como .github/skills, .claude/skills ou .agents/skills. Já as skills pessoais ficam em ~/.copilot/skills e valem para todos os projetos.
Como seguem um padrão aberto, as skills podem ser compartilhadas e reutilizadas entre projetos e entre agentes de fornecedores diferentes. Inclusive, a mesma skill funciona no agente de código, no modo agente do VS Code e no GitHub Copilot CLI.
Se você está em dúvida sobre quando criar um agente e quando expor uma ferramenta por MCP, vale ler a comparação Agents ou MCP: qual escolher. Afinal, as duas peças se complementam no terminal.
Boas práticas para o dia a dia
Antes de liberar o agente, vale adotar alguns cuidados que a própria documentação sugere. Primeiro, inicie as sessões sempre na pasta do projeto, e nunca na pasta pessoal.
Em seguida, prefira permissões granulares a --allow-all-tools, principalmente em máquinas com credenciais de produção. Também vale revisar cada pull request criado pelo /delegate com o mesmo rigor de um código humano.
Outro cuidado importante é escrever instruções personalizadas para o projeto, explicando como compilar, testar e organizar o código. Com isso, o agente deixa de adivinhar convenções e passa a seguir as regras que o time já usa.
Além disso, o recurso Copilot Memory guarda um entendimento persistente do repositório entre as sessões. Assim, você repete menos explicações sobre a arquitetura e economiza contexto em cada conversa.
Por fim, documente os agentes e as skills do time dentro do repositório. Dessa forma, qualquer pessoa que clonar o projeto ganha os mesmos fluxos especializados sem configuração manual.
Para quem trabalha com .NET, o artigo sobre Copilot CLI e SDK no ecossistema .NET mostra como levar esses agentes para dentro das aplicações.
Vídeo de demonstração do GitHub Copilot CLI
O vídeo abaixo serviu de fonte para este artigo e mostra os principais comandos em funcionamento. Vale assistir para ver o fluxo completo, da instalação à delegação.
Considerações finais sobre o GitHub Copilot CLI
O GitHub Copilot CLI redefine a forma como interajo com o terminal, porque integra agentes, automação e contexto avançado ao fluxo de desenvolvimento. Ao combinar slash commands, MCP, delegação assíncrona e compartilhamento de sessões, a ferramenta se torna um multiplicador de produtividade.
Mais do que um assistente, o Copilot no terminal se apresenta como um ambiente extensível, capaz de evoluir junto com as necessidades do time. Portanto, a adoção consciente desses recursos pode representar um ganho real em eficiência, qualidade e foco.
FAQ
Preciso pagar para usar o GitHub Copilot CLI?
A ferramenta exige uma assinatura do Copilot, mas está disponível em todos os planos. O consumo de créditos varia conforme o modelo escolhido.
Qual a diferença entre /delegate e o modo interativo?
No modo interativo, o agente trabalha na sua máquina e pede aprovações. Já o /delegate envia a tarefa ao agente de código do Copilot, que trabalha na nuvem e abre um pull request em rascunho.
Onde fica a configuração dos servidores MCP?
A configuração fica no arquivo ~/.copilot/mcp-config.json. Você também pode adicionar servidores pelo comando /mcp add durante a sessão.
É seguro usar a opção --allow-all-tools?
A documentação classifica a opção como de alto risco, porque o agente executa comandos sem confirmação. Prefira liberar ferramentas específicas com --allow-tool e bloquear as perigosas com --deny-tool.
Skills e agentes personalizados são a mesma coisa?
Não, porque o agente define uma especialidade completa com instruções e ferramentas. Já a skill é um pacote de instruções e recursos que qualquer agente carrega quando a tarefa pede.