You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
This looks like a bug: the -R flag for gh search code silently returns no results when given a full GitHub URL (e.g., https://github.com/cli/cli) instead of either stripping the URL to OWNER/REPO or returning a clear error. No duplicate issues were found. I'm suggesting bug and priority-3 — it's a real defect but a workaround exists (use OWNER/REPO format directly).
This is expected because the -R/--repo flag on gh search isn't the same flag as the -R on repo-scoped commands like gh issue list or gh pr view. On those commands, -R selects a single base repository and accepts a few forms, including a full URL, which gets parsed down to OWNER/REPO.
On gh search, --repo is a repository filter that can take multiple values and passes them straight through to GitHub's search syntax as repo:OWNER/REPO. That qualifier only understands the OWNER/REPO form, so -R https://github.com/cli/cli becomes repo:https://github.com/cli/cli and matches nothing.
So the behavior is working as intended, but the flag's help text didn't make the expected format clear. I've opened #13922 to add an OWNER/REPO format hint to the --repo flag help across the gh search commands. In the meantime, use the OWNER/REPO form (-R cli/cli). Thanks for surfacing it!
Thank you for your issue! We have categorized it as an enhancement (feature or improvement) request, and it has been added to our backlog. In doing so, we are not committing to implementing this feature at this time, but, we will consider it for future releases based on community feedback and our own product roadmap.
Unless you see the
help wantedContributions welcome
label, we are not currently looking for external contributions for this feature.
If you come across this issue and would like to see it implemented, please add a thumbs up! This will help us prioritize the feature. Please only comment if you have additional information or viewpoints to contribute.
Activity
cli-triage commentedon Jul 13, 2026
This looks like a bug: the
-Rflag forgh search codesilently returns no results when given a full GitHub URL (e.g.,https://github.com/cli/cli) instead of either stripping the URL toOWNER/REPOor returning a clear error. No duplicate issues were found. I'm suggestingbugandpriority-3— it's a real defect but a workaround exists (useOWNER/REPOformat directly).BagToad commentedon Jul 20, 2026
Thanks for the issue!
This is expected because the
-R/--repoflag ongh searchisn't the same flag as the-Ron repo-scoped commands likegh issue listorgh pr view. On those commands,-Rselects a single base repository and accepts a few forms, including a full URL, which gets parsed down toOWNER/REPO.On
gh search,--repois a repository filter that can take multiple values and passes them straight through to GitHub's search syntax asrepo:OWNER/REPO. That qualifier only understands theOWNER/REPOform, so-R https://github.com/cli/clibecomesrepo:https://github.com/cli/cliand matches nothing.So the behavior is working as intended, but the flag's help text didn't make the expected format clear. I've opened #13922 to add an
OWNER/REPOformat hint to the--repoflag help across thegh searchcommands. In the meantime, use theOWNER/REPOform (-R cli/cli). Thanks for surfacing it!github-actions commentedon Jul 20, 2026
Thank you for your issue! We have categorized it as an enhancement (feature or improvement) request, and it has been added to our backlog. In doing so, we are not committing to implementing this feature at this time, but, we will consider it for future releases based on community feedback and our own product roadmap.
Unless you see the help wantedContributions welcome
label, we are not currently looking for external contributions for this feature.
If you come across this issue and would like to see it implemented, please add a thumbs up! This will help us prioritize the feature. Please only comment if you have additional information or viewpoints to contribute.
BagToad commentedon Jul 20, 2026
Fixed by #13922