Entre 23/09 e 14/10/2026, os 13 artigos de troubleshooting que publicamos aqui no blog saíram de issues do GitHub. Nas três semanas anteriores, 8 de 9 tinham saído do Reddit. A troca não foi planejada: aconteceu porque, rodada após rodada, a issue mais comentada da semana num repositório oficial entregava o que o post do Reddit não entregava, que é a mensagem de erro literal, a versão e, às vezes, a resposta do mantenedor.
Este guia mostra o método inteiro, com os quatro comandos do gh (GitHub CLI) que usamos, os filtros que aprendemos a acertar e o critério para descartar uma issue antes de escrever. Serve para quem mantém documentação, faz suporte de uma ferramenta ou só quer saber o que está quebrando para todo mundo antes de quebrar para você.
Qual comando lista as issues mais comentadas de um repositório?
É o gh search issues com --sort comments, filtrado por data de criação. Este é o comando que roda no começo de cada rodada:
gh search issues --repo openai/codex --state open \
--created ">=2026-10-08" --sort comments --limit 5 \
--json number,title,commentsCount \
--jq '.[] | "\(.commentsCount)\t#\(.number)\t\(.title)"'Rodado em 15/10/2026, ele devolveu no topo a #52407, com 93 comentários em seis dias, o erro MXC launcher ... HRESULT 0x80070003 do Codex no Windows. Foi essa issue que virou o artigo de 14/10.
Os flags que importam, conferidos no gh search issues --help da versão 2.100.0:
| Flag | O que faz | Por que usamos |
|---|---|---|
--sort comments | Ordena por número de comentários | Comentário é gente afetada tentando resolver. É o melhor indicador de dor que o GitHub oferece |
--created ">=AAAA-MM-DD" | Só issues abertas a partir da data | Corta as issues antigas que só voltaram a receber comentário |
--state open | Só issues abertas | Problema ainda vivo. Fechada com fix vira outro tipo de artigo |
--json + --jq | Escolhe os campos e formata a saída | Uma linha por issue, fácil de ler e de passar para um script |
Um detalhe da documentação do próprio comando: a busca semântica (--search-type semantic ou hybrid) ordena por relevância e não aceita --sort. Para ranquear por comentário, fique na busca padrão.
Por que filtrar por --created e não por --updated?
Porque --updated traz de volta issues antigas que receberam um comentário ontem. Rodamos as duas versões do mesmo comando no repositório do Codex em 15/10/2026, com data de corte 08/10:
| Filtro | O que apareceu no top 5 |
|---|---|
--updated ">=2026-10-08" | 2 das 5 eram antigas: um pedido de recurso aberto em 18/06 e outro de 14/01 (pedindo o /undo de volta) |
--created ">=2026-10-08" | As 5 eram desta semana, incluindo uma aberta em 14/10 que já tinha 44 comentários |
Pedido de recurso antigo é pauta legítima, mas é outro tipo de pauta. Para achar o erro que está pegando todo mundo agora, a data que importa é a de criação.
Outro filtro que não dá para automatizar: número de comentários não é sinônimo de bug. No mesmo dia, o top 5 do anthropics/claude-code tinha um pedido de interface de volta e um desabafo sem erro nenhum. Leia os títulos antes de abrir qualquer coisa.
Como transformar uma issue em várias variações do mesmo erro?
Busque a mensagem de erro literal, entre aspas, no mesmo repositório. Uma issue mostra um caso; a busca mostra o padrão.
gh search issues "SIGSEGV" --repo anthropics/claude-code \
--created ">=2026-08-01" --limit 100 --json number,title,createdAtEm 15/10/2026 essa busca devolveu 58 issues criadas desde 01/08. Foi assim que, em 27/09, um candidato que parecia nicho (uma issue só) virou o artigo sobre SIGSEGV no Claude Code: lendo as issues da busca, apareceram três causas diferentes para a mesma mensagem, cada uma com um caminho de saída. O artigo virou uma tabela por variação em vez de uma resposta única que serviria para um terço dos leitores.
Como ler a issue inteira sem sair do terminal?
Com gh issue view e a flag --comments, que imprime a descrição e todos os comentários em sequência:
gh issue view 52407 --repo openai/codex --commentsO que procuramos em cada thread, nessa ordem:
- A mensagem literal, copiada do log de quem reportou. É ela que o leitor vai colar na busca.
- A versão exata do app ou do CLI em que o erro aparece e em que some.
- Resposta de mantenedor, PR de correção ou release citado.
- Contorno que mais de uma pessoa confirmou. Contorno de um usuário só entra atribuído a ele, nunca como solução.
Para saber se a issue já foi fechada com correção, sem ler a thread toda:
gh issue view 52407 --repo openai/codex --json state,closedAt,labelsComo conferir no código-fonte antes de escrever?
Quando o projeto é aberto, leia o arquivo que gera a mensagem. O gh api devolve o conteúdo cru com o header certo:
gh api repos/openai/codex/contents/codex-rs/mxc-sandbox/src/windows.rs \
-H "Accept: application/vnd.github.raw" | grep -n "cannot locate required"Em 15/10/2026 isso aponta a linha 131 do arquivo, onde a mensagem do 0x80070003 é montada. É a diferença entre escrever "usuários dizem que o erro vem do launcher" e "o erro sai da função tal, neste arquivo". Quando o projeto é fechado, a fonte equivalente é a documentação oficial de erros, se existir.
Quando descartar uma issue em vez de escrever sobre ela?
Quando, depois de ler a thread e procurar na fonte, não há causa confirmada nem correção. Relato sem confirmação não vira artigo, por mais comentada que a issue seja. Os três motivos de descarte que mais usamos:
| Situação | O que fazemos |
|---|---|
| Sem causa nem correção, só especulação nos comentários | Descarta. Em 11/10 trocamos um erro 403 com 4 comentários e só hipóteses por outra issue cuja mensagem estava na documentação oficial |
| Erro já coberto por artigo nosso | Pula para a próxima. Em 11 e 12/10 a issue mais comentada do Codex era um erro que já tínhamos publicado em 10/10 |
| Bom candidato, mas ainda cedo | Anota o número na fila e volta na próxima rodada. Em 07/10 o artigo saiu direto de um candidato anotado na véspera |
Por que trocamos o Reddit pelas issues do GitHub?
Porque a issue já chega no formato que um artigo de troubleshooting precisa. O post do Reddit é ótimo para sentir o humor da semana, mas quase sempre exige uma segunda pesquisa para virar algo verificável.
| Atributo | Post no Reddit | Issue no repositório oficial |
|---|---|---|
| Mensagem de erro literal | Às vezes, em print | Quase sempre, em texto copiável |
| Versão afetada | Raramente | Costuma ser campo do template de bug |
| Resposta de quem mantém | Rara | Quando existe, fica na thread, com link para PR ou release |
| Checagem de fato necessária | Sempre: em 05/09 um número popular estava impreciso e o ângulo mudou | Menor, porque dá para conferir no código |
| Melhor para | Limite, preço, mudança de política | Erro com mensagem, crash, regressão de versão |
O Reddit não saiu do processo. Ele segue sendo a fonte certa para assunto de limite e cobrança, que não tem issue. Para erro com mensagem, a issue ganhou em todas as 13 rodadas.
Dá para rodar tudo de uma vez em vários repositórios?
Dá. Este laço lista as 5 issues novas mais comentadas dos últimos 7 dias em três repositórios de agentes de programação (no macOS, troque a data por date -v-7d +%F):
for repo in openai/codex anthropics/claude-code google-gemini/gemini-cli; do
echo "== $repo"
gh search issues --repo "$repo" --state open \
--created ">=$(date -d '7 days ago' +%F)" --sort comments --limit 5 \
--json number,title,commentsCount \
--jq '.[] | "\(.commentsCount)\t#\(.number)\t\(.title)"'
doneA parte que não automatiza é o julgamento: ler a thread, conferir na fonte e descartar quando não fecha. É também a parte que mais consome contexto, porque uma issue de 90 comentários é longa. Um agente de programação no terminal pode rodar o laço, abrir as threads e resumir o que cada uma confirma, e é aí que o custo por leitura pesa: na Verboo Code os tokens são ilimitados, então ler a thread inteira custa o mesmo que ler o título.
