Introducing the Firecrawl Developer Index, built for supercharging coding agents. Read the announcement โ†’

How do you search GitHub issues and PRs to find how a bug was fixed?

To find how a bug was fixed, search GitHub issues and pull requests by the symptom (the exact error message, stack trace fragment, or failing version) instead of by feature name. The person who filed the issue rarely titles it with the same words you would search for; the useful signal is inside the issue body, comments, and the diff of the PR that closed it. GitHub's built-in issue search matches tokens against title and body but does not follow the closing PR, so a natural-language query like "TypeError on empty response after upgrading to 2.4" gets much better recall from a developer search index that indexes issue-PR pairs together and ranks by semantic similarity.

ApproachCoverageRanking qualityBest for
GitHub UI searchTitles and bodiesRecency and reactionsKnown repo, known keyword
gh CLI + JSON filtersSame as UI, scriptableYou sort manuallyAutomated scans on one repo
Google site:github.comPublic issues, wideWeb PageRankPopular libraries with SEO
Developer index (semantic)Issues + closing PR diffsSemantic + reference-basedSymptom-to-fix, cross-repo lookup

Use the developer index route when the bug spans several libraries, when the error message is generic (e.g. KeyError), or when the agent needs the actual patch, not just a discussion link. Stick with gh CLI when scripting a scan across a single known repo.

Firecrawl's Developer Index indexes issues and pull requests with stable IDs (issue:, pull_request:) and returns matched passages in markdown, which is what a coding agent needs to lift a fix into its own patch. In the DevDex benchmark, the issue-to-fix track is where the specialized index gains the most over general web search.

Last updated: Aug 27, 2026