gh CLI ou GitHub MCP no Claude Code: qual usar para mexer em issues e pull requests?

Fala aí, beleza? Na superfície os dois caminhos fazem a mesma coisa: abrir issue, abrir pull request, ler comentário, tudo sem sair do Claude Code

Só que eles cobram preços bem diferentes em contexto, permissão e configuração inicial

E aqui vai o ponto que costuma passar batido: a escolha não é sobre qual é mais moderno, é sobre o tipo de trabalho que tu faz no repositório 😀

Quem vive abrindo branch e PR o dia inteiro tem uma resposta. Quem precisa ler log de workflow quebrado, alerta de segurança ou travar escrita por política da equipe tem outra

Bora comparar os dois com calma?

O que o gh CLI resolve dentro do Claude Code

O gh é a CLI oficial e open source do GitHub, instalável em macOS, Windows e Linux

Se tu já usa qualquer ferramenta de linha de comando, a curva aqui é curtinha: é o GitHub inteiro respondendo no terminal

A documentação de boas práticas do Claude Code é direta nisso: instale o gh, porque o Claude sabe usá-lo para criar issues, abrir pull requests e ler comentários

E tem um detalhe que quase ninguém conta: sem o gh, o Claude ainda consegue falar com a API do GitHub, só que requisição não autenticada costuma bater no limite de taxa

Pré-inscrição Formação Claude Code

Domine o Claude Code do básico ao avançado

Você vai aprender a criar sistemas completos com Claude Code, sem precisar ser programador. Inscreva-se para ter acesso a um desconto de lançamento e bônus especiais!

Quero minha vaga

Cobertura de issues e pull requests:

Do lado das issues, o gh issue cobre criar, triar, atribuir e fechar

gh issue create
gh issue list
gh issue close

Se liga nisso: o gh issue list aceita a MESMA sintaxe de filtro da busca do GitHub, então o filtro que tu já monta na interface web funciona no terminal

Do lado dos PRs, a lista de subcomandos do gh pr é completona: create, list, status, checkout, checks, close, comment, diff, edit, lock, merge, ready, reopen, revert, review, unlock, update-branch e view

A sessão vinculada ao PR:

Esse é o argumento mais forte do gh e ele é meio escondido

Quando o PR nasce de um gh pr create dentro do Claude Code, a sessão fica automaticamente vinculada ao PR criado

Depois tu reabre aquela conversa do jeito que preferir:

claude --from-pr 1234

Ou colando a URL do PR na busca do seletor /resume

Ou seja: o contexto de por que aquele PR existe não morre quando tu fecha o terminal, muito massa 🙂

O que o GitHub MCP Server entrega de diferente

O servidor MCP do GitHub é oficial, mantido no repositório github/github-mcp-server

E existe uma versão remota hospedada pelo próprio GitHub, numa URL HTTP fixa: https://api.githubcopilot.com/mcp/

Remota significa duas coisas boas: atualização automática e nada de instalação local

O que vem por padrão:

Por padrão o servidor entrega quatro frentes:

• inteligência de repositório: buscar código e ler arquivos
• automação de issues e pull requests: abrir, triar, rotular, revisar, mesclar
• visibilidade de CI/CD: inspecionar execuções de workflow, buscar logs, reexecutar jobs
• insights de segurança: alertas de code scanning e Dependabot

Repara que as duas últimas frentes são justamente o que a conversa de issue e PR no terminal não cobre

E como isso vira ferramenta pro Claude?

Boa pergunta, porque muda o jeito de dar permissão

Toda ferramenta MCP no Claude Code segue o padrão mcp__<nome-do-servidor>__<nome-da-ferramenta>

Então um servidor chamado github com a ferramenta list_issues vira mcp__github__list_issues

E tome cuidado com isso: ferramenta MCP exige permissão explícita antes de o Claude usar

Sem permissão ele VÊ que a ferramenta existe e simplesmente não consegue chamar, o que gera aquela sensação de "instalei e não funcionou"

gh CLI x GitHub MCP: comparação linha a linha

A linha do custo de contexto merece um parágrafo à parte

A busca de ferramentas vem ligada por padrão no Claude Code: em vez de carregar as definições MCP no contexto de largada, entram só os nomes e as instruções do servidor

O Claude usa uma ferramenta de busca pra descobrir as relevantes quando a tarefa exige, e só as efetivamente usadas entram no contexto

Massa, né? O medo antigo de "MCP come minha janela inteira" mudou de figura por causa disso

Como configurar cada um (e o erro comum de cada passo)

Vou separar em dois caminhos, e a numeração segue direto pra tu não se perder

Caminho A: gh CLI

1. Rode o login e escolha o destino (GitHub.com ou Enterprise Server) e depois o método (navegador ou token de autenticação)

gh auth login

O erro comum deste passo: escolher Enterprise Server no automático quando o repositório é GitHub.com, ou o contrário. Leia a pergunta antes de apertar enter 😛

2. Confira quem ficou logado antes de sair mandando comando

gh auth status

O erro comum deste passo: pular a conferência e descobrir só depois que a conta autenticada não é a que tem acesso ao repositório. O gh também respeita a variável GITHUB_TOKEN, então vale lembrar dela quando o resultado vier estranho

Caminho B: GitHub MCP remoto

3. Adicione o servidor remoto por HTTP com o header de autorização

claude mcp add --transport http github https://api.githubcopilot.com/mcp/ --header "Authorization: Bearer YOUR_GITHUB_PAT"

O erro comum deste passo: tentar resolver isso por OAuth. Pro Claude Code e pro Claude Desktop a orientação é PAT mesmo; o fluxo completo de OAuth remoto está disponível no VS Code 1.101 ou superior

4. Confira se o servidor entrou e como ele está

claude mcp list
claude mcp get github

Dentro da sessão, o /mcp mostra o estado da conexão do servidor

5. Libere as ferramentas que tu realmente quer usar

O erro comum deste passo é aquele que citei lá em cima: a ferramenta aparece, o Claude não chama, e tu acha que o servidor está quebrado

Dá pra usar allowedTools pra aprovar ferramentas MCP específicas sem prompt, em vez de aprovar tudo na mão a cada vez

6. Desfez a ideia? Remover é uma linha

claude mcp remove github

Quando cada escolha é a mais simples

Fluxo de branch e PR no dia a dia:

Aqui o gh ganha fácil

É zero setup extra, é o caminho que a própria documentação do Claude Code recomenda, e ainda tem o bônus da sessão vinculada ao PR criado com gh pr create

Pra quem trabalha em várias frentes, reabrir com claude --from-pr 1234 é o tipo de coisa que economiza aquele tempo todo de "o que eu estava fazendo mesmo aqui?"

Repositório sensível, onde a equipe quer travar escrita:

Agora o MCP brilha

O header X-MCP-Readonly habilita apenas ferramentas de leitura, e ele é o equivalente da variável GITHUB_READ_ONLY do servidor local

O detalhe que faz diferença: o modo somente leitura tem PRECEDÊNCIA sobre qualquer outra configuração, desabilitando ferramentas de escrita mesmo se forem pedidas explicitamente

Esse é exatamente o tipo de guardrail que vale combinar antes de rodar o agente em repositório de cliente, quando o código não é teu e a régua é do outro lado

Investigar workflow quebrado e log de CI:

MCP de novo, porque esse toolset vem por padrão: inspecionar execuções de workflow, buscar logs e reexecutar jobs

É o cenário clássico do "o pipeline caiu e eu não sei por quê"

Permissão fina, ação por ação:

O servidor MCP do GitHub ganhou suporte a configuração específica por ferramenta, e as opções são combináveis: toolsets, ferramentas individuais, ferramentas excluídas, modo somente leitura e modo lockdown

Dá pra desenhar uma política bem cirúrgica, coisa que com comando de terminal tu resolveria só no grito das regras de permissão

Os dois juntos:

E tem esse cenário, que é o mais honesto de todos

Não existe regra dizendo que tu precisa escolher UM

gh pro fluxo de issue e PR do cotidiano, MCP pra leitura de CI/CD e segurança com escrita travada, cada um fazendo o que faz melhor

Veredito: qual eu ligaria primeiro

Começa pelo gh, sem drama

Ele é a recomendação da própria documentação do Claude Code, resolve issue e pull request com comandos dedicados e não pede configuração extra nenhuma além do login

Depois, quando aparecer uma necessidade REAL, tu liga o GitHub MCP: leitura de execução de workflow e logs, alertas de code scanning e Dependabot, ou uma política de somente leitura que precisa valer mesmo quando alguém pede escrita explicitamente

E o que NÃO justifica trocar: a ideia de que MCP deixa o Claude mais capaz por si só

Não deixa

MCP é superfície de ferramenta e controle de permissão, não inteligência extra. Se o teu problema é o agente errando o alvo, trocar o encanamento não resolve

Conclusão

Recapitulando rapidinho: gh é a CLI oficial, cobre issue e PR com comandos dedicados e vincula a sessão ao PR criado

O GitHub MCP é o servidor oficial, entra por HTTP no Claude Code com PAT, e traz CI/CD, segurança e trava de escrita como diferencial

O próximo passo prático é bem chato de tão simples: roda um gh auth status e descobre onde tu já está

Aí sim, olhando pro teu repositório, decide se o MCP resolve alguma coisa que o gh não resolve

até o próximo post! =)