How to Review Pull Requests in VS Code 2026

How to Review Pull Requests in VS Code 2026

TL;DR: Three real methods for reviewing pull requests inside VS Code, ranked by what your team actually needs. The GitHub Pull Requests extension covers GitHub-only teams with 34.5 million installs behind it. Claude Code CLI gives solo developers an AI pre-review pass before they hit "Request review." Git AutoReview is the cross-platform option — GitHub, GitLab, and Bitbucket from one extension with a human approval gate on every AI suggestion. This guide covers setup, the trade-offs, and which one fits your situation.

The reason developers want PR review inside VS Code is the same reason they wanted code completion inside VS Code in the first place. The browser version is functional but flat. You can read a diff and leave comments, but you cannot jump to the definition of the function being changed, search for every caller of the modified method, or run the test suite against the new branch. All of that context lives in your editor — which is exactly where you already do the rest of your work.

This guide walks through three methods, each with a different fit. Method 1 is the most installed PR extension on the Marketplace and works only for GitHub. Method 2 is a terminal-based AI pre-review you can run before pushing. Method 3 is our own product, built specifically because the first two leave most multi-platform teams underserved. The decision guide at the end is honest about when each method wins.

Prerequisites

• VS Code installed (current stable build)
• A GitHub, GitLab, or Bitbucket account with at least one repository
• git installed locally and configured with your user identity

Why review PRs inside VS Code instead of the browser?

The github.com PR interface works, but it does not give you the editor. Reviewing in the browser means you cannot use go-to-definition on the function being changed, you cannot run callers searches against the rest of the codebase, and you cannot execute tests against the branch without manually cloning and checking it out. For anything beyond a one-file typo fix, that limitation costs you accuracy. Reviewers either rubber-stamp because the diff "looks fine" or they bounce between tabs trying to rebuild context every five minutes.

Two specific bugs in the GitHub web UI are worth calling out because they shape how teams actually behave. As Aaron Meurer documents on asmeurer.com, GitHub has two parallel comment systems — immediate comments and delayed "start a review" comments — and if you forget to press "Review changes" at the end, your delayed comments never get sent to anyone. Meurer also points out that the GitHub PR list shows no review status, so reviewers cannot tell at a glance which PRs are waiting on them. The same blog notes that negative review states persist after the author addresses the concerns, which forces unrelated reviewers into the loop just to clear the block.

PullFlow, which builds tools specifically for this problem, identifies tool context-switching as the top drag on review productivity. Their framing is direct: switching between IDE and review tools forces you to rebuild mental context every time. Gloria Mark's UC Irvine research on context switching put the cost of full focus recovery at around 23 minutes — and while that figure was measured across general office work rather than PR review specifically, anyone who has tried to review a complex diff between Slack notifications recognizes the pattern.

The IDE solves all of that. You stay in one window, your file tree stays loaded, your test runner stays warm, and your AI assistant — if you use one — has the same project context whether you are writing code or reviewing it.

Method 1 — GitHub Pull Requests Extension (GitHub-only, free)

The GitHub Pull Requests extension is the default answer for any team on GitHub. Microsoft and GitHub publish it directly, the install count sits at over 34 million, and the feature set covers everything a browser-based reviewer can do plus several things they cannot. The catch is the platform scope — it works with GitHub and GitHub Enterprise Server only. No GitLab, no Bitbucket.

Setup

1. Open the Extensions panel in VS Code (Ctrl+Shift+X on Windows/Linux, Cmd+Shift+X on macOS).
2. Search for "GitHub Pull Requests" — confirm the publisher is GitHub.
3. Click Install. A GitHub icon appears in the Activity Bar on the left.
4. Click the GitHub icon, then click "Sign In." VS Code opens your browser for OAuth.
5. Approve access in the browser. The tab redirects back to VS Code.
6. Your repository's pull requests appear in the sidebar, grouped by category.
7. Click any PR to expand the changed files. Click a file to open the diff view.
8. Hover any line in the diff and click the + icon to add an inline comment. When you finish, click "Submit Review" and pick Approve, Request Changes, or Comment.

Virtual review vs checkout

The extension offers two review modes, and the choice matters more than most developers realize. Virtual review mode lets you read diffs and leave inline comments without ever changing your local branch — useful when you are mid-work on your own feature and do not want to stash, switch, and restore. Checkout mode does what it sounds like: right-click any PR in the sidebar, pick "Checkout Pull Request," and the extension switches your working tree to the PR branch.

Virtual mode is faster but partial. You see the diff, you can leave comments, you submit a review. What you do not get is IntelliSense against the branch's actual code, the ability to run tests, or full project navigation. Checkout mode gives you all of that — at the cost of disrupting whatever you were doing before. For anything security-sensitive or architecture-affecting, checkout is the honest choice. For a documentation fix or a one-line config change, virtual is enough.

What this extension is good at

The strongest part of this extension is how seamless it makes GitHub-native workflow inside the editor. CI status from GitHub Actions shows next to the PR. Edits to the PR description, labels, assignees, and reviewers all happen in-editor without a browser tab. Comment threads work like any other VS Code editor view — you can drag across multiple lines to leave a range comment, reply directly to other reviewers, and resolve threads once addressed.

Limitations

The platform restriction is the headline limitation. The extension reads "GitHub Pull Requests" on the marketplace because that is exactly what it does, and not a feature beyond it. The rating is 4 out of 5 stars across 139 reviews, and the user complaints that show up consistently are about background API requests in rate-limited environments — the extension polls aggressively, which can hit GitHub's REST limits on shared OAuth tokens.

If your team uses only GitHub and does not need AI-assisted review, this is the right tool and you do not need to read further. If you need anything beyond GitHub, keep going.

Method 2 — Claude Code CLI Pre-Review (GitHub + terminal output for any platform)

The second method is fundamentally different from the first. The GitHub Pull Requests extension is a UI replacement for github.com inside VS Code. Claude Code CLI is an AI pre-review pass that happens in your terminal — typically before you push, sometimes after, occasionally as a sanity check on a colleague's PR before you review it manually. This is the method solo developers on Claude Pro reach for most often.

One important distinction up front. Claude Code CLI is the terminal tool that ships with Claude Pro. The managed Claude Code Review service is a separate GitHub App that auto-triggers on every PR open and posts comments automatically — that one requires a Team plan at $100/seat and is not what this section covers.

What you need

Claude Pro costs $20/mo on the monthly plan or $17/mo on the annual plan ($200/yr). Claude Code is included in that subscription — there is no separate purchase. You do not pay $100/mo for standalone Claude Code; that figure refers to Max plans, which are a different product entirely. For details on what Claude Code includes and how the BYOK setup works inside Git AutoReview, the Claude Code documentation page covers both paths.

Install

Pick one command for your operating system:

# macOS or Linux (universal installer)
curl -fsSL https://claude.ai/install.sh | bash

# macOS via Homebrew
brew install --cask claude-code

# Windows PowerShell
irm https://claude.ai/install.ps1 | iex

Run claude for the first time. It will open your browser to log in to your Claude Pro account.

The review workflow

1. Open the terminal inside VS Code (`Ctrl+`` opens the integrated terminal).
2. cd into the project you want to review.
3. Run claude to start a session.
4. Type /code-review and press enter. The output appears directly in the terminal.
5. Optional, GitHub only: /code-review --comment posts the findings as a PR comment instead of printing them. This requires the gh CLI installed and authenticated.

You can also skip the slash command and write in natural language. review PR #42 works. review PR #42, focus on security and error handling works too. The model picks up the intent.

What /code-review actually does

Behind the slash command, the plugin runs a structured pipeline. First it checks whether the PR is closed, marked as draft, trivially small, or already reviewed — and skips if any of those conditions hit. Then it reads any CLAUDE.md files in the project to pick up your guidelines (style preferences, security rules, naming conventions you care about). It generates a PR summary, then launches four parallel agents: two cross-check the diff against your CLAUDE.md rules, one looks for bugs, and one runs git blame to add historical context to each finding.

Every issue gets a confidence score between 0 and 100. Only findings scoring 80 or higher get reported. The plugin deliberately ignores code style, naming conventions, anything a linter would already catch, pre-existing bugs that the PR did not introduce, and pedantic nitpicks. The goal is signal — not the firehose of 50 comments per file that diff-only bots tend to produce.

Limitations

The --comment flag is GitHub-only because it routes through the gh CLI from cli.github.com, which only supports GitHub. Terminal output works for any platform — GitLab, Bitbucket, anything — but the comment-posting integration does not. Mark that as unverified for GitLab and Bitbucket; you can run the analysis on any repo, you just cannot one-command it into a merge request comment.

The other limitation is automation. Pro users run /code-review manually, one PR at a time. Nothing triggers automatically when a teammate opens a PR. If you want every PR to get an AI pass without anyone having to remember, that is the managed Claude Code Review service on the Team plan — a different product with different pricing. For solo developers and small teams who want AI sanity-checking on their own work before requesting human review, the manual flow is exactly the right shape. If the PRs you are reviewing were themselves written by AI, the 12-item checklist for AI-generated code gives Claude (or your reviewer) a structured pass that catches hallucinated packages, cross-file side effects, and OWASP-class security gaps that diff-only review often misses.

Method 3 — Git AutoReview (GitHub + GitLab + Bitbucket, AI with human approval)

The third method is our product, and we will be honest about where it fits. Git AutoReview was built because the first two methods leave a specific group of developers underserved: multi-platform teams, GitLab Self-Managed shops, Bitbucket Server and Data Center customers, and anyone who wants AI review with an explicit approval step before any comment hits the PR. If you are a GitHub-only team that just wants the GitHub Pull Requests extension to work better, this is not the article that should sell you on switching.

The core idea is straightforward. Git AutoReview is a VS Code extension that reads your PR, runs it through Claude, GPT, or Gemini — whichever model you bring a key for — and surfaces the findings inside the editor. You then review each finding, approve the ones that matter, edit any that need refinement, and publish only the approved set to the PR. The AI suggests; you decide. That is the entire workflow philosophy, and it shows up in the tagline.

Setup

1. Open VS Code Marketplace, search "Git AutoReview," install.
2. Open the Git AutoReview panel in the sidebar.
3. Paste your AI provider API key on first run (Anthropic, Google, or OpenAI).
4. Connect your Git account — GitHub PAT, GitLab token, or Bitbucket App Password depending on platform.

Setup typically takes about two minutes. We deliberately do not use a GitHub App or webhook — the extension talks directly from your VS Code to your AI provider, and the only credentials that touch our infrastructure are the ones you choose to sync for team features (license, settings). Your code never passes through us.

The review workflow

Open a PR in the sidebar. Click "Review" — pick Quick Review for a 15-30 second pass that reads the diff, or Deep Review for a 2-5 minute pass that runs through Claude Code CLI and explores the surrounding codebase. The model produces a list of findings, each with a severity, a file/line reference, and the suggested change. You step through them. Each finding has three options: approve (it will publish to the PR), edit (refine the comment first), or skip (it will not publish). When you finish the review, only your approved comments post — under your own GitHub/GitLab/Bitbucket identity, not a bot account.

The Deep Review documentation covers what changes between Quick and Deep Review modes in more detail, including which AI providers each mode supports.

Platform support

This is the part that drives most of the migrations we see. Git AutoReview works on:

• GitHub (Cloud and Enterprise Server)
• GitLab (Cloud and Self-Managed)
• Bitbucket Cloud
• Bitbucket Server
• Bitbucket Data Center

One extension, five deployment targets. If your team uses two platforms because of a merger, an acquisition, or just historical accident, you stop needing two extensions and two review workflows.

Pricing

Three plans. Free at $0 — 10 reviews per day, one repository. Developer at $9.99/mo — 100 reviews per day, ten repositories. Team at $14.99/mo flat (not per user) — unlimited reviews, all repositories.

Because this is a BYOK product, the AI compute is separate. You pay your AI provider directly at their published per-token rate. For typical use on a working PR queue, that runs about $2-5/mo paid to Anthropic, Google, or OpenAI depending on which model you pick and how much you review. ~$2–5/mo AI compute costs paid directly to AI provider (Anthropic/Google/OpenAI bills you separately).

That structure means total cost for a 10-person team on Team plan is $14.99 + ~$5/mo API ≈ $20/mo. The equivalent CodeRabbit setup would be $240/mo at $24/user. We are not faster than CodeRabbit. We do catch a different category of issues because the model runs in your IDE with your full project context, and the approval gate eliminates the noise problem entirely — but on raw speed of "open PR, get bot comment," CodeRabbit's webhook-based flow has the structural advantage.

Which method should you use?

We will not pretend one method wins every scenario. The honest answer depends on which platform you use, how big the team is, and whether you want AI in the loop at all.

For a GitHub-only team that does not want AI in the workflow at all, the GitHub Pull Requests extension is the right answer and you can stop here. The 34.5 million installs are not an accident — it does what it says, it ships from Microsoft and GitHub directly, and it integrates cleanly with the rest of the GitHub ecosystem (Actions, Issues, the works).

For a solo developer on Claude Pro working in a GitHub repo, the most useful pattern is to chain Method 1 and Method 2. Run /code-review from Claude Code CLI in the terminal before you push — catch your own bugs, fix them, then push a cleaner commit. After you push, open the PR in the GitHub Pull Requests extension and do the manual review yourself. That gives you AI sanity-checking without paying for a team-scale automated service.

For any team that lives on GitLab or Bitbucket — Cloud or Self-Managed/Server/DC — Method 3 is the option that exists. The other two extensions on the Marketplace cover their platforms (GitLab Workflow for GitLab, Atlassian for VS Code for Bitbucket), but neither does AI review. For multi-platform shops, Git AutoReview consolidates the workflow and adds the approval gate that auto-publishing tools deliberately skip.

For a large GitHub-only organization that wants every single PR to get an AI pass automatically without anyone clicking anything, the managed Claude Code Review service on a Team plan is the structural fit. It runs as a GitHub App, triggers on every PR open, and posts inline comments — at $100/seat that is the right price point only if you genuinely need the automation. If you want approval-gated AI review at lower cost with the same multi-platform coverage, Git AutoReview Team at $14.99/mo flat covers it. The full pricing page breaks down both routes including annual options. For the deeper philosophical case on auto-publish vs human approval, our AI PR review guide walks through the data.

The ecosystem context matters here too. GitLens from GitKraken sits at over 40 million installs, according to GitKraken, and is the most popular git extension overall — but GitLens is git context, not PR review. GitLab Workflow handles GitLab merge requests but does no AI. Atlassian for VS Code sits at over 2 million installs and handles Bitbucket PRs without AI. Git AutoReview is the only one of these that crosses all three Git platforms and adds AI review with an approval step.

FAQ

Related resources

• AI PR Review Guide 2026 — deeper comparison of CodeRabbit, Copilot, Bugbot, and Git AutoReview with verified pricing
• Claude Code CLI documentation — Git AutoReview's Deep Review integration with Claude Code
• Deep Review — what changes when you run agent-mode review on your full codebase
• Pricing — Free, Developer, Team plans with annual options