How to find the most commented issues in a repository with gh search issues

Between Sep 23 and Oct 14, 2026, all 13 troubleshooting articles we published on this blog came from GitHub issues. In the three weeks before that, 8 out of 9 had come from Reddit. We did not plan the switch. It happened because, round after round, the most discussed issue of the week in an official repository gave us what the Reddit post did not: the literal error message, the version and, sometimes, a reply from the maintainers.

This guide shows the whole method: the four gh (GitHub CLI) commands we use, the filters we learned to get right, and the rule for dropping an issue before writing about it. It is useful if you maintain docs, do support for a tool, or just want to know what is breaking for everyone before it breaks for you.

Which command lists the most commented issues in a repository?

gh search issues with --sort comments, filtered by creation date. This is the command that starts every round:

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)"'

Run on Oct 15, 2026, it put #52407 at the top, with 93 comments in six days: the MXC launcher ... HRESULT 0x80070003 error in Codex on Windows. That issue became our Oct 14 article.

The flags that matter, checked against gh search issues --help in version 2.100.0:

Flag	What it does	Why we use it
--sort comments	Sorts by number of comments	Comments are affected people trying to fix it. It is the best pain signal GitHub offers
--created ">=YYYY-MM-DD"	Only issues opened on or after the date	Cuts old issues that just got a new comment
--state open	Only open issues	The problem is still live. Closed with a fix is a different kind of article
--json + --jq	Picks fields and formats the output	One line per issue, easy to read and to pipe into a script

One detail from the command's own help: semantic search (--search-type semantic or hybrid) ranks by relevance and does not accept --sort. To rank by comments, stay on the default search.

Why filter by --created instead of --updated?

Because --updated brings back old issues that got one comment yesterday. We ran both versions of the same command on the Codex repository on Oct 15, 2026, with an Oct 8 cutoff:

Filter	What showed up in the top 5
--updated ">=2026-10-08"	2 of 5 were old: a feature request opened on Jun 18 and another from Jan 14 (asking for /undo back)
--created ">=2026-10-08"	All 5 were from this week, including one opened on Oct 14 that already had 44 comments

An old feature request is a fair topic, but a different one. To find the error that is hitting everyone right now, creation date is what counts.

One filter you cannot automate: comment count does not mean bug. The same day, the top 5 in anthropics/claude-code included a request to bring a UI option back and a rant with no error at all. Read the titles before opening anything.

How do you turn one issue into several variants of the same error?

Search the literal error message, in quotes, in the same repository. One issue shows one case; the search shows the pattern.

gh search issues "SIGSEGV" --repo anthropics/claude-code \
  --created ">=2026-08-01" --limit 100 --json number,title,createdAt

On Oct 15, 2026 this search returned 58 issues created since Aug 1. That is how, on Sep 27, a candidate that looked niche (a single issue) became our article on SIGSEGV in Claude Code: reading the search results surfaced three different causes behind the same message, each with its own way out. The article became a table by variant instead of one answer that would fit a third of the readers.

How do you read the full issue without leaving the terminal?

With gh issue view and the --comments flag, which prints the description and every comment in order:

gh issue view 52407 --repo openai/codex --comments

What we look for in each thread, in this order:

1. The literal message, copied from the reporter's log. That is what the reader will paste into a search.
2. The exact version of the app or CLI where the error shows up and where it goes away.
3. A maintainer reply, a fix PR or a release mentioned.
4. A workaround confirmed by more than one person. A single user's workaround goes in attributed to them, never as the solution.

To check whether the issue was closed with a fix, without reading the whole thread:

gh issue view 52407 --repo openai/codex --json state,closedAt,labels

How do you check the source code before writing?

When the project is open source, read the file that builds the message. gh api returns the raw content with the right header:

gh api repos/openai/codex/contents/codex-rs/mxc-sandbox/src/windows.rs \
  -H "Accept: application/vnd.github.raw" | grep -n "cannot locate required"

On Oct 15, 2026 this points to line 131 of the file, where the 0x80070003 message is built. It is the difference between writing "users say the error comes from the launcher" and "the error comes from this function, in this file". When the project is closed source, the equivalent is the official error documentation, if it exists.

When should you drop an issue instead of writing about it?

When, after reading the thread and checking the source, there is no confirmed cause and no fix. An unconfirmed report is not an article, however many comments it has. The three drop reasons we use most:

Situation	What we do
No cause, no fix, only speculation in the comments	Drop it. On Oct 11 we swapped a 403 error with 4 comments and only guesses for another issue whose message was in the official docs
Error already covered by one of our articles	Skip to the next one. On Oct 11 and 12 the most discussed Codex issue was an error we had already published on Oct 10
Good candidate, but too early	Note the number in the queue and come back next round. On Oct 7 the article came straight from a candidate noted the day before

Why did we switch from Reddit to GitHub issues?

Because an issue already arrives in the shape a troubleshooting article needs. A Reddit post is great for reading the mood of the week, but it almost always needs a second round of research to become something verifiable.

Attribute	Reddit post	Issue in the official repo
Literal error message	Sometimes, in a screenshot	Almost always, as copyable text
Affected version	Rarely	Usually a field in the bug template
Reply from the maintainers	Rare	When it exists, it is in the thread, linked to a PR or release
Fact-checking needed	Always: on Sep 5 a popular number turned out to be imprecise and the angle changed	Less, because you can check the code
Best for	Limits, pricing, policy changes	Errors with a message, crashes, version regressions

Reddit did not leave the process. It is still the right source for limits and billing, which have no issue. For errors with a message, the issue won in all 13 rounds.

Can you run it all at once across several repositories?

Yes. This loop lists the 5 most commented new issues from the last 7 days in three coding agent repositories (on macOS, swap the date for 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)"'
done

The part that does not automate is judgment: reading the thread, checking the source and dropping it when it does not hold up. It is also the part that eats the most context, because a 90-comment issue is long. A coding agent in the terminal can run the loop, open the threads and summarize what each one confirms, and that is where the cost per read adds up: with Verboo Code tokens are unlimited, so reading the whole thread costs the same as reading the title.