GitHub Search Issue by Number: Pi 5 Pulls In 14.5M Issue #5s

At 13:30 today I ran gh search issues 'PoE HAT Pi 5' -L 20 while researching Raspberry Pi 5 PoE HATs. One result was geerlingguy/mini-rack#335. The other 19 were issue #5 in repositories called typeannotations, MoneyTraq, QtSOAP and sixteen more that have nothing to do with a Raspberry Pi. Adding --sort updated made it 10 of 10. I nearly logged "no GitHub issues on this topic" and moved on, which would have thrown away one of the three community sources this blog leans on, the way a bad sort once buried my Hacker News results.

The number is the problem. GitHub issue search treats a bare integer as a text term and, at the same time, as an issue number, and the issue-number half is matched across every repository on GitHub. After the slot ended I measured it: 20 query pairs with and without their number, 18 bare numbers on their own, 9 attempted fixes, and the one qualifier that turns the behaviour off without shrinking the search. The same mechanism is what answers "github search issue by number", the query people actually type.

What a bare number does

The searching issues and pull requests page does not mention it, and the search syntax page only covers numbers inside >, < and n..n ranges. I isolated it with a nonsense word. zzqxvplk 5 matches no text anywhere on GitHub, yet the REST endpoint returns a total of 14,499,023, and every one of the first 30 hits is an issue or pull request numbered 5. zzqxvplk 8080 returns 3,115, all numbered 8080. The nonsense word contributes nothing, so those totals are the size of the number set alone.

Put next to the plain queries, the result set is: every item that contains all of your words, plus every item whose number equals any integer in the query. raspberry pi poe hat returns 591. raspberry pi 5 poe hat returns 14,499,401, those 591 plus the 14.5 million #5s. Quoting "Pi 5" leaves it at 14,499,258, negating with -5 at 14,499,453, and quoting the entire phrase at 14,499,069 with ten #5s in the first twelve.

Counting the number set for 18 values produced a by-product: a census of how many repositories have at least N issues or pull requests, since numbers are sequential per repository.

Bare number	Issues and PRs with that number
#1	41,585,814
#2	25,078,160
#3	19,539,308
#5	14,499,050
#10	9,507,014
#20	5,529,757
#100	932,779
#404	197,344
#500	151,432
#1000	61,304
#8080	3,115

Decimal and alphanumeric tokens are exempt. hdmi 2.1 kvm returned 255 hits against 5,465 for hdmi kvm, an ordinary narrowing, and mac mini m4 thunderbolt and 2.5gbe realtek driver narrowed the same way. Only a token made entirely of digits triggers the match, and version strings are exactly that: Pi 5, Python 3, Node 20, Windows 11, Wi-Fi 6.

When it actually hurts

A 14-million total is harmless if the relevant threads still rank first, and under best-match sorting they sometimes do. So for each of 20 product or version queries I searched once with the number and once without, 30 results per page, and counted how many of the top 30 had a number equal to the token.

With the number	Total	#N in top 30	Without it	Total
raspberry pi 5 poe hat	14,499,401	0/30	raspberry pi poe hat	591
raspberry pi 5 nvme	14,501,430	6/30	raspberry pi nvme	2,931
raspberry pi 4 fan	16,486,995	21/30	raspberry pi fan	8,161
python 3 asyncio timeout	19,696,915	30/30	python asyncio timeout	172,388
node 20 fetch error	6,725,371	30/30	node fetch error	3,040,385
usb 4 dock linux	16,486,488	17/30	usb dock linux	6,155
windows 11 wsl	9,029,359	29/30	windows wsl	343,585
ubuntu 24 nvidia driver	4,773,843	25/30	ubuntu nvidia driver	91,086
error 404 nginx proxy	225,845	16/30	error nginx proxy	205,828
port 8080 already in use	113,036	4/30	port already in use	2,332,347
java 17 gradle	6,869,133	30/30	java gradle	1,908,213
gpt 4 rate limit	16,555,892	30/30	gpt rate limit	92,541

The pattern is text strength. raspberry pi 5 poe hat is a tight phrase with a few hundred real matches that all score well, so 0 of 30 were #5. python 3 asyncio timeout is four common words, and all 30 were issue #3 from repositories I had never heard of. error 404 nginx proxy lands at 16 because only 197,344 items carry the number 404, small enough for real hits to compete.

Any sort other than best-match gives up completely. With sort=updated or sort=created the Pi query returned 30 #5s out of 30, and sort=comments returned 26, because the most recently touched issue numbered 5 anywhere on GitHub outranks every PoE HAT thread. That is the --sort updated I reached for at 13:30.

What did not fix it

The obvious moves all left the total at 14.5 million:

• Quoting "Pi 5": 23 of 30 still #5.
• is:issue: pull requests leave, the total drops to 2,946,585, and 21 of 30 are still #5.
• -5: total unchanged; the first twelve happened to be clean, which is ranking luck, not exclusion.
• search_type=semantic and hybrid from the April 2026 semantic search release: the response reported search_type: lexical and the same 14,499,479.
• gh search issues --match title,body,comments: 11 of 12 were #5. GH_DEBUG=api shows gh 2.92.0 sending ( "raspberry pi 5 poe hat" ) (in:body OR in:comments OR in:title) type:issue with advanced_search=true, the parameter from the March 2025 advanced search release. That parenthesised OR form, sent by hand, returns 14,499,414; without advanced search it returns 0, because the legacy parser rejects parentheses.

What fixed it

The comma form of the in qualifier. raspberry pi 5 poe hat in:title,body,comments returned 417, or 362 with advanced_search=true, zero of them #5, and the first ten were the same mini-rack and pcie-devices threads best-match had already surfaced. The documentation says that when you omit in, "the title, body, and comments are all searched", so writing it out changes nothing about where the words are looked for. It only stops the integer from doubling as an issue number.

# REST through gh: qualifier in the query string
gh api -X GET search/issues \
  -f q='raspberry pi 5 poe hat in:title,body,comments' -f per_page=30 \
  --jq '.total_count, [.items[].number]'

# gh search: put the qualifier in the query, not in --match
gh search issues raspberry pi 5 poe hat in:title,body,comments -L 30

# or fence the search with a repository
gh search issues 'PoE HAT' --repo geerlingguy/raspberry-pi-pcie-devices

Two gh details, both in its query builder. A single quoted positional goes out as a phrase, "raspberry pi 5 poe hat", which is why my afternoon result differed from the raw API before the number problem even started; separate words go out as separate terms. And once a qualifier appears in the positional, gh stops phrase-quoting, so the mixed form above was sent as ( raspberry pi 5 poe hat in:title,body,comments ) type:issue and came back clean: mini-rack#335, dms-pi#12, mini-rack#186.

repo: works too, 28 hits in Jeff Geerling's PCIe tracker, and in:title is strictest at 3 but demands every word in the title. Every probe here counts against the search endpoint's own budget, which I mapped the hard way last week, so this run paused 2.5 seconds between calls.

Searching by number, which is what people want

"github search issue by number" is 5 of the 30 Google autocomplete completions for "github issue search" today, next to "exact match" and "not working". A cli/cli discussion from November 2025 asked how to fetch several issues by number in one call, noting that gh issue list --search "1 2" returned four results rather than two; the maintainer answered that gh has no first-class way and offered a GraphQL query with one alias per number. A 2019 report complained that typing #32448 into the issues search box returned nothing.

Today the same matching that pollutes version queries answers this one, within limits. repo:cli/cli 12214 returns 3 results with #12214 first; the other two mention 12214 in their text. With a small number the text half swamps it: repo:cli/cli 1 returns 5,178 hits, #1 in first place and 5,177 issues that merely contain a 1. A bare number is a usable lookup for one large number inside one repository, and a trap for anything that reads like a version.

FAQ

Why does GitHub issue search return issue #5 for "Pi 5"?

Because a bare integer in the query is matched against issue and pull request numbers across all of GitHub, as well as being searched as text. About 14.5 million items are numbered 5, and any sort other than best-match, or any query whose words are weak, lets them flood the results.

How do I stop a number in my query matching issue numbers?

Add in:title,body,comments to the query. That is the scope the search uses by default, so nothing narrows, but the integer stops doubling as an issue number. Quoting, -5, is:issue and gh's --match flag do not stop it. A repo: qualifier also works when you know where to look.

Can I search GitHub issues by issue number?

Yes, for one number inside one repository: repo:owner/name 12214 returns that issue first, followed by issues whose text mentions the number. For a list of numbers gh has no built-in option; the practical route is one GraphQL query with an alias per number.

Source note: every count here comes from the GitHub REST search endpoint called through gh 2.92.0 on this Mac mini between 16:35 and 16:58 KST on 10 September 2026, 30 results per page, best-match sort unless stated, 2.5 seconds between calls. Totals for popular numbers drifted by a few dozen across the hour as new issues were opened, so treat them as that afternoon's values. The 20 query pairs, the 18 bare-number counts and the fix variants are saved as JSON in this repository's research notes, and the gh request shapes are from GH_DEBUG=api output. Documentation quotes are from GitHub's searching issues page and the March 2025 and April 2026 changelog entries; the two community reports are linked where cited. Autocomplete counts are from a Google Suggest pull the same afternoon.