Repository navigation
BUG: gh pr list and issue list --label uses OR logic instead of AND logic #419
Description
Activity
Thanks for the issue! Just want to note that this is also relevant for issues. We're going to discuss this and determine a way forward.
Reacted by Patrick Veith- addedneeds-designAn engineering task needs design to proceedAn engineering task needs design to proceed
on Feb 14, 2020 - changed the title
[-]BUG: gh pr list --label uses OR logic instead of AND logic[/-][+]BUG: gh pr list and issue list --label uses OR logic instead of AND logic[/+]on Feb 14, 2020 - addedbugSomething isn't workingSomething isn't workingand removedneeds-designAn engineering task needs design to proceedAn engineering task needs design to proceed
on Feb 14, 2020 After a discussion, we agree and think that the best way forward here for now is to do what @dterhorst describes above, mirroring how github.com filters when there are multiple labels specified.
Proposed solution: If you have multiple labels specified, the list should only show those issues or PRs that match all of the specified labels, not any.
While we're also attracted to the idea of full boolean logic, we're going to punt on that for now until we get more signal that that's something a lot of people are going to want to use.
Note: We may be limited by what we get from the API to use AND logic instead of the existing OR logic, so we're discussing ways forward.
Reacted by dterhorst-zz, Patrick Veith, Keith Wedinger, Mark Wahba, Mislav Marohnić, Flavio Miyamoto, Johannes Bühler, Yuan (Bob) Gong and Mat Schaffer- addedpriority-2Affects more than a few users but doesn't prevent core functionsAffects more than a few users but doesn't prevent core functions
on Feb 14, 2020 Is there any progress on this, the current behaviour is quite annoying and limiting.
@coot We are waiting on the corresponding GraphQL APIs to be finalized on the platform side.
Reacted by cootReacted by dterhorst-zz@mislav thanks for letting me/us know
Looks like about a quarter since the last update. Was hoping to use
hubin one less place but this means I'll be keeping it around for the time being.Any news on the GraphQL APIs?
@matschaffer Thanks for checking in! We got access to some APIs for this that are under preview (not available to the general public) but we will likely need a few more weeks to ship something built on top of that. 🙇
Reacted by Rom'sThanks for the update!
Hey Guys.
What's the latest on this one? It would be super helpful for all sorts of planning exercises.
Our use case is similar to the original enquirer. But ticket type rather than team.
e.g. Priority: High, Medium, Low
Type: Bug, Enhancement, HelpI have a team focused on all High Priority Bugs. So being able to search for issues with labels 'Bug' AND 'High Priority' would be super helpful.
Thank you.
@andysanders No updates yet. We will likely have to switch to the Search API internally to get AND labels.
In the meantime, you can query the Search API directly:
gh api -X GET search/issues \ -F q='repo::owner/:repo is:issue is:open label:"bug" label:"high priority"' \ --jq '.items[] | [.number,.title] | @tsv'
- added a commit that references this issue
on Jul 21, 2025
Describe the bug
gh pr list --labelappears to be using OR logic instead of AND logicgh pr list --labelsometimes contains duplicates.To show why this is a problem, imagine your PRs have the following labels:
in progress,ready for review, andreviewedteam a,team b, andteam c.Now let's say you want to find all of the PRs that are
ready for reviewfromteam b.So it makes sense that you try to search for
--label "ready for review,team b". However, instead of getting a list of every PR that is both "ready for review" and "team b," you get:These results are useless from the perspective of someone who wants to review PRs from
team bthat areready for review.Steps to reproduce the behavior
test-aandtest-ctest-bandtest-cgh pr list -l test-a,test-cExpected vs actual behavior
Expected:
Actual:
Broken expectations:
test-alabel and therefore doesn't satisfy the given query.Possible solutions
At minimum, use AND by default.
Ideally, support full boolean logic:
Logs