# GitHub Pull Requests and Issues for VS Code: Reviewing PRs Without Leaving the Editor

> The official GitHub extension for VS Code brings pull request review, issue browsing and branch checkouts into the editor. It is a workflow tool, not a CI system, and its value depends on how much of your review process already lives on GitHub.

**microsoft/vscode-pull-request-github** — GitHub Pull Requests for Visual Studio Code

- Repository: https://github.com/microsoft/vscode-pull-request-github
- Website: https://marketplace.visualstudio.com/items?itemName=GitHub.vscode-pull-request-github
- Stars: 2,629 · Forks: 798
- Language: TypeScript
- License: MIT
- Published: 2026-09-28 · Updated: 2026-09-28 · Language: en
- Canonical page: https://hysenlabs.com/projects/microsoft-vscode-pull-request-github

## What the extension actually replaces

The extension targets a narrow but frequent interruption: you are editing code, someone asks for a review, and the review lives in a browser. GitHub Pull Requests and Issues moves that loop into VS Code. According to the README, it supports authenticating VS Code to GitHub and GitHub Enterprise, listing and browsing pull requests, reviewing them with in-editor commenting, checking out a PR branch, listing and browsing issues, hover cards for mentioned users and issues, completion suggestions for users and issues, a Start working on issue action that creates a branch, and code actions that turn todo comments into issues.

The audience is developers who already use GitHub as their review system and VS Code as their editor. It is not a general Git client and not a code review server. If your team reviews on GitLab, Bitbucket or Gerrit, none of the mechanisms here apply, because the extension talks to GitHub's API through VS Code's authentication provider, not to an arbitrary forge.

## How the extension is wired into VS Code

The package.json shows the architecture more clearly than the README does. The extension declares an extensionDependencies entry on vscode.github-authentication, so sign-in is delegated to a separate VS Code authentication extension rather than implemented in this repository. It registers several custom file system schemes, including newIssue, pr, githubpr, githubcommit and review, which is how PR diffs and issue views get their own virtual documents. It also contributes a chat context provider under the githubpr scheme and declares a long list of enabled API proposals, among them commenting, commentReactor, quickDiffProvider and tabInputMultiDiff. Those proposals are pre-release VS Code APIs, which is a real constraint: the extension's engines field requires vscode ^1.137.0, so it cannot run on older VS Code builds.

The activation events confirm the lazy design. The extension starts on onStartupFinished, onOpenExternalUri for http and https, on the custom file systems above, and on webview panels named IssueOverview and PullRequestOverview. In practice the PR tree is populated from GitHub search queries, and the queries themselves are user-editable, which is the most interesting design decision in the whole project.

## Installing it and configuring the PR tree

The README gives a five-step path. Install from within VS Code or from the marketplace download link, open a GitHub repository, find the new viewlet on the activity bar, use its button to sign in, and adjust the remotes setting if your clone does not use origin and upstream.

```json
{
  "githubPullRequests.remotes": ["origin", "upstream"]
}
```

The README states the extension will look for PRs for origin and upstream by default, and that you may need to configure githubPullRequests.remotes if you have different remotes. After installation, opening a GitHub repository should add a viewlet to the activity bar showing pull requests and issues, and the sign-in button on that viewlet starts the GitHub authentication flow.

The default queries are Waiting For My Review, Assigned To Me and Created By Me. Adding a category means editing githubPullRequests.queries with a label and a GitHub search query, using ${user} as the placeholder for your own login. The README's example adds a Mentioned Me category built on the query is:open mentions:${user}.

```json
"githubPullRequests.queries": [
	{
		"label": "Waiting For My Review",
		"query": "is:open review-requested:${user}"
	},
	{
		"label": "Assigned To Me",
		"query": "is:open assignee:${user}"
	},
	{
		"label": "Created By Me",
		"query": "is:open author:${user}"
	},
	{
		"label": "Mentioned Me",
		"query": "is:open mentions:${user}"
	}
]
```

Issue categories work the same way through a separate githubIssues.queries setting. Queries use GitHub search syntax, so anything the search box accepts should work here.

## The queries setting is the real interface

Most VS Code extensions expose toggles. This one exposes a search language. githubPullRequests.queries is a list of label and query pairs, and the tree is only as useful as the queries you write. That is a genuine advantage for teams with an unusual review convention, because a category like is:open review-requested:${user} can be expressed without waiting for a feature request.

The cost is that the extension inherits every quirk of GitHub search syntax. A malformed query produces an empty or wrong category rather than a validation error, and the README points to GitHub's own search syntax documentation instead of documenting the accepted subset. There is no query builder, no preview, and no indication in the README of how often the tree refreshes. If your team relies on saved searches in the browser, expect to port them by hand and test each one.

## Where it stops being the right tool

The README is explicit that the extension is still in development and points readers to the issue tracker for known issues. That is not boilerplate: it means you should expect rough edges and should not treat the extension as the system of record for review state. GitHub remains the system of record. The extension is a client.

Three concrete limits follow. First, everything depends on GitHub authentication through vscode.github-authentication, so an offline or air-gapped environment cannot use it at all. Second, GitHub Enterprise users are routed to the wiki for authentication guidance, which suggests the enterprise path has enough variation that it is not covered in the README. Third, the extension only looks at the remotes you configure. A repository cloned with a nonstandard remote name will show an empty viewlet, and the README's troubleshooting step for that is a settings change, not an error message. Anyone who has debugged a silent empty tree knows how much time that costs.

There is also a maintenance angle worth stating plainly. The last push to the repository was on 2026-09-16, and the most recent releases listed are v0.162.0 and v0.160.0, both dated 2026-07-29, with v0.158.0 on 2026-07-22. The version in package.json is 0.166.1. Release cadence on the marketplace and version bumps in the repository do not move in lockstep, so a reader comparing the two should check the changelog rather than assume the marketplace listing reflects main.

## How it compares with reviewing on github.com

The obvious alternative is not another extension. It is github.com in a browser tab. The difference in approach is where the diff renderer lives. GitHub's web UI renders diffs server-side with its own comment threads, review summaries and approval buttons. This extension renders diffs through VS Code's diff editor and comment API, which means you get syntax highlighting, your editor theme, jump-to-definition and the ability to check out the branch and run the code in the same window.

What you give up is the parts of review that are not the diff. Review summaries, required approvals, protected branch rules and merge queue behavior are GitHub features, and the README does not claim to reproduce the whole review workflow. In-editor commenting is listed; approval workflows are not. If your process depends on review states that only the web UI exposes, the extension will send you back to the browser for that step. The honest framing is that the extension shortens the read-and-comment loop and leaves the governance loop where it was.

## Licence and upgrade cost

The repository is MIT licensed, which permits commercial use, modification and redistribution provided the copyright notice and permission notice are included. The extension is published to the marketplace by the GitHub publisher, and it depends on vscode.github-authentication, so your authentication data flows through VS Code's authentication machinery rather than through this codebase. Nothing in the README or package.json suggests a paid tier or a licence key. This is a description of the licence text, not legal advice; if you vendor or fork the extension, read the LICENSE file in the repository.

Upgrade cost is dominated by the engine requirement. The engines field pins vscode to ^1.137.0 and node to >=20, and the extension enables a large set of API proposals. API proposals can change between VS Code releases, which is why the extension tracks recent VS Code versions closely. Teams that pin an older VS Code build for other extensions may find this one will not install or will lose features. Check the changelog before upgrading VS Code, and check the changelog again before upgrading the extension, because the two move together.

## Conclusion

Adopt it if your team reviews on GitHub and you want to read diffs, comment and check out branches without a browser tab. Skip it if you review on GitLab, Bitbucket or Gerrit, or if you need offline review, since authentication and PR data both come from GitHub. Before rolling it out, confirm that the remote names in your clone match the githubPullRequests.remotes setting, because the default only looks at origin and upstream, and check the wiki FAQ for your authentication path if you are on GitHub Enterprise.

## FAQ

### How do I create a pull request in VS Code with this extension?

The README lists a Start working on issue action that can create a branch for you, and code actions that create issues from todo comments. Creating the pull request itself is not described in the README, which points to the wiki FAQ for further questions.

### How do I pull from GitHub in VS Code using the GitHub Pull Requests and Issues extension?

The extension's stated support includes validating PRs with easy checkouts, so you can check out a pull request branch from within VS Code. The README does not document a general fetch or pull command for arbitrary branches.

### How to pull a request from VS Code to GitHub?

The README does not describe a push or upload command. It lists reviewing PRs, checking out PR branches, and listing and browsing issues as the supported actions, with the wiki FAQ covering authentication questions.

### How to do a GitHub pull request?

The README covers browsing, reviewing and checking out pull requests inside VS Code, plus a Start working on issue action that creates a branch. It does not document the steps for opening a new pull request on GitHub itself.

## Sources

- [License: MIT](https://github.com/microsoft/vscode-pull-request-github/blob/main/LICENSE)
- [microsoft/vscode-pull-request-github on GitHub](https://github.com/microsoft/vscode-pull-request-github)
- [Project website](https://marketplace.visualstudio.com/items?itemName=GitHub.vscode-pull-request-github)
- [README](https://github.com/microsoft/vscode-pull-request-github/blob/main/README.md)
- [Releases](https://github.com/microsoft/vscode-pull-request-github/releases)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/microsoft-vscode-pull-request-github