You find an issue that looks open. No assignee, no linked PR, a clear bug report. You spend an evening on a fix, open a PR, and then learn that someone else already has one waiting in review.
This happens a lot, and it isn't carelessness. A GitHub issue page doesn't reliably tell you whether anyone is working on the issue. It misses that work in at least five ways.
1. The PR never links to the issue
An issue page lists a PR only if the PR says "Fixes #80" or the author links it by hand. Many PRs do neither. The issue looks untouched while a fix sits in review.
2. The project moved
Libraries often move into a monorepo or a new org. The old issue stays open, the fixes are opened in the new repository, and the old issue page can't see them.
3. Claims live in the comments
People write "I'd like to work on this" or /assign without ever being assigned. You only find out by reading the whole thread.
4. The maintainers already said no
Somewhere in the thread there's "won't fix", "duplicate of #…", or a label like needs discussion that blocks outside work for now.
5. The project doesn't take outside PRs
The issue is free, but nobody outside the core team has had a PR merged in a year. Your fix will sit there.
A real example
date-fns/tz#80: tzOffset gets the sign wrong for offsets between -01:00 and 00:00. On the issue page it looks open and free. In fact:
- the project has moved to
date-fns/date-fns; - two open PRs there already fix it (#4314 and #4279), and neither mentions issue #80;
- the last outside PR was merged 14 months ago.
None of that shows up on the issue page. Checking by hand means searching PRs in two repositories, reading every comment and looking at the merge history, for every issue you're considering. Most people skip it.
Automating the check
I wrote gh-claimcheck, a GitHub CLI extension that runs these checks and gives a verdict: GO, CAUTION or SKIP.
$ gh claimcheck date-fns/tz#80
! An open PR looks like the same fix
date-fns/date-fns#4314: Fix tzOffset returning the wrong sign for sub-hour western offsets
! An open PR looks like the same fix
date-fns/date-fns#4279: fix(tz): correct tzOffset sign for negative offsets of less than an...
! Project has moved to date-fns/date-fns
! The last outside PR was merged 14 months ago
✓ Issue is open
✓ Nobody is assigned
CAUTION An open PR looks like the same fix
It looks at linked and referencing PRs, PRs with similar titles (ranked by how close they are), "moved to" notices in the README, claims in comments, maintainer pushback, blocking and welcoming labels, who wrote the last 40 merged PRs, and the project's contributing guide and AI policy. Your own claims and PRs never count against you.
It's read-only: it never comments, assigns or opens anything, and it uses your existing gh login.
Finding issues, not just checking them
Two commands go the other way and look for issues that pass:
# Beginner-friendly Go issues that come out GO
gh claimcheck find --good-first-issue --lang go --go-only
# Open, unclaimed issues in the libraries your project already uses
gh claimcheck deps --check
deps reads your manifests and lock files (npm, PyPI, Go modules, Cargo, Maven/Gradle, RubyGems, Composer, pub, Hex, NuGet, Swift, GitHub Actions, Docker and more), finds each library's GitHub repository, and searches them. This is often the best place to contribute: you already know the library, and you can test the fix in your own app.
Limits
Claim and pushback detection read plain-English comments, and title matching is fuzzy. A CAUTION means "go and look", not "don't". When in doubt, ask on the issue; maintainers almost always prefer that.
Try it
gh extension install RagedPanda/gh-claimcheck
gh claimcheck <issue-url>
It's MIT licensed, written in Go, with prebuilt binaries for macOS, Linux and Windows. Issues and PRs are welcome, and false positives are especially useful to report.
