GitHub Copilot Code Review Not Running on Pull Requests? A Diagnostic Checklist

Short answer. A Copilot review that does not appear on a pull request is almost always one of eight things, and they are worth checking in this order because each earlier one makes the later ones irrelevant: the plan does not include code review; the organization policy has it off; no ruleset targets this branch, or the ruleset is set to Evaluate rather than Active; the pull request is a draft and drafts are not enabled; the review already ran and you pushed afterwards without Review new pushes; the author is someone the automatic trigger does not cover; the pull request is from a fork; or — rarely — a manual request was never made and there is no automatic ruleset at all. Each has a check that takes under a minute, and the checklist below gives the evidence for each.

The automatic code review lesson explains how to set this up well. This page is for when it is set up and nothing happened.

Product facts were read from GitHub’s documentation on 18 September 2026 and are linked where used. Copilot code review changes often; if this page and your repository’s settings screen disagree, the settings screen is current.

First, which kind of review did you expect?

Two different mechanisms produce a Copilot review, and half of “it is not running” reports come from expecting one while having configured the other.

A manual request. On any pull request, under Reviewers in the right sidebar, Copilot appears as a reviewer with a Request button. Clicking it runs a review once; GitHub says it “usually takes less than 30 seconds”. This needs a plan that includes code review and — in an organization — the policy enabled. It needs no ruleset.

An automatic review. A branch ruleset with Automatically request Copilot code review selected, at repository, organization or enterprise level; or, for Pro, Pro+ and Max subscribers, the Automatic Copilot code review option in your own Copilot settings, which covers pull requests you create. Automatic reviews fire on specific events — opening a pull request, or the first time a draft is switched to open — and on nothing else unless the ruleset says so.

If you never configured a ruleset and never pressed Request, nothing is broken. Press Request. If it works, the diagnosis is “you wanted automatic review and have not enabled it”, and the lesson’s ruleset walkthrough is the fix.

Eligibility: plan and policy

Plan. GitHub’s concept page states code review is “available for all paid Copilot plans” and, in the usage section, that Copilot Free “does not include Copilot code review”. A Free user requesting a review gets nothing to request. Organizations on Business or Enterprise can additionally allow members without a licence to use code review on GitHub.com, but only when two policies are enabled — “AI credits paid usage” first, then “Allow members without a Copilot license to use Copilot code review” — and that second policy is disabled by default and “most restrictive”: it applies only in organizations where it was explicitly turned on.

Organization policy. The same page: “If you receive Copilot from an organization, your organization must enable the Copilot code review option in the Copilot policy settings. This applies to reviews on GitHub.com or in GitHub Mobile.” An organization owner finds it under Settings → Copilot → Policies. If it is off, the Request button does nothing useful and no ruleset can help.

Evidence to collect: which plan you are on (the Plan Finder lists what each includes), and whether Request next to Copilot in the Reviewers menu is present and responds. If it responds and a review appears, eligibility is not your problem and the rest of this page is about the automatic trigger.

Is a ruleset targeting this branch, and is it active?

This is the largest single cause, and the lesson’s troubleshooting section names it first: enforcement status, then branch targeting, then repository targeting.

Enforcement status. A ruleset has three states — Disabled, Evaluate and Active. Evaluate records what the rules would have done without doing it, which is useful for a dry run and indistinguishable from “nothing happened” if you forgot the ruleset is in that state. GitHub’s configuration steps say: “To activate the ruleset, under Enforcement Status, select Active.”

Branch targeting. The rule applies to pull requests whose target branch matches — “Include default branch”, “Include all branches”, or a pattern. A pull request into release/2.4 is not covered by a ruleset that includes only the default branch. Open the ruleset and read the Target branches block against the base branch of the pull request that got no review.

Repository targeting, for organization rulesets. Include and exclude patterns are applied in that order, and GitHub’s example — include *cat*, exclude not-a-cat — is exactly the shape that catches people: an exclusion pattern written for one repository can match several. The organization ruleset page shows which repositories it currently targets.

Is the pull request a draft?

Automatic review triggers, per GitHub’s concept page, on two events under the basic setting: “When you create a pull request as an ‘Open’ pull request” and “The first time you switch a ‘Draft’ pull request to ‘Open’”. A draft pull request gets no automatic review unless the ruleset’s Review draft pull requests option is selected.

So a draft that has been open for a day with no review is behaving as configured. Mark it ready for review and the review runs; or enable the draft option if you want feedback before that point — GitHub describes it as “useful for catching errors early, before requesting a human review”, and the lesson’s section on drafts covers the noise trade-off.

Did the review already run, before your last push?

The most common “it stopped working” report. GitHub is explicit: “Unless Copilot has been configured to review each push to a pull request, it will only review a pull request once.” A pull request that was reviewed on open, then received five more commits, has one review — on the first version of the diff — and nothing on the later commits.

Two remedies. Enable Review new pushes in the ruleset, which makes every push a review and, as the lesson notes, is a cost and noise decision as much as a coverage one. Or request a re-review by hand: “click the button next to Copilot’s name in the Reviewers menu”. GitHub adds a caution worth knowing before you do — on re-review “Copilot may repeat the same comments again, even if they have been dismissed”.

Evidence: the pull request timeline. Find the Copilot review, note its timestamp, and compare it with the commits after it. If every commit you care about is newer than the review, this is the cause.

Is the author someone the trigger covers?

Repository and organization rulesets automatically review pull requests “created by people with access to Copilot” — GitHub’s words on the concept page. A pull request opened by a collaborator who has no Copilot seat is not reviewed automatically, unless the organization has enabled review for members without a licence as described above. The same page says that, when that policy is on, automatic reviews “also apply to pull requests created by organization members without a license” in the covered repositories.

Bot-authored pull requests are handled: for pull requests authored by Copilot cloud agent, usage is attributed to the human co-author, and for “other bots, or when a bot requests the review, usage is billed directly to the organization. These pull requests are eligible for agentic review.” So a Dependabot pull request without a review is not excluded by authorship — check the ruleset targeting first.

Evidence: the author’s seat status in Settings → Copilot → Access for the organization, and whether the pull request was opened by a person, a bot or the cloud agent.

Is it a fork?

The lesson’s fork section covers the governance side. For diagnosis, the practical point is that a pull request from a fork is opened by an outside contributor who typically has no Copilot access in your organization, and instruction files in the pull request are contributor-supplied content. If reviews appear on internal branches and not on fork pull requests, that is the trigger’s authorship rule above, not a fault — and whether you want automatic review on outside contributions is a decision to make deliberately.

Did the review run but not do what you expected?

Three variants of “not working” where a review did in fact happen.

It ran as a Comment, and the merge is still blocked. By default “Copilot leaves a ‘Comment’ review, not an ‘Approve’ review”, and “Copilot’s reviews do not count toward required approvals”. Copilot approvals exist, in public preview, and are off by default; enabling them and letting them count toward merge requirements are two separate toggles under the repository’s Copilot → Code review settings, and an organization or enterprise policy can forbid them. A review that does not unblock a merge is the default, not a failure.

It ran, but without the “agentic” context. Code review uses GitHub Actions for its agentic capabilities — full-repository context gathering and handing suggestions to the cloud agent. GitHub says: “If GitHub Actions is unavailable or if Actions workflows used by Copilot code review fail, reviews will still be generated. However, they will not include the additional features.” And: “If your organization has disabled GitHub-hosted runners, the agentic capabilities will not be available.” So a thin review after an Actions outage or on an organization with hosted runners off is a limited review, not a missing one. If you customised the review’s environment with .github/workflows/copilot-code-review.yml or copilot-setup-steps.yml, a failing step there degrades the review the same way; the setup-steps article covers debugging those files.

It ran and said nothing about some files. The lesson lists the exclusions: dependency-management files, logs and SVGs are not reviewed, and content exclusion removes files from review as it does from everything else.

It ran and did not follow your instructions. Code review reads .github/copilot-instructions.md, path-specific .instructions.md files, AGENTS.md, and — GitHub adds — CLAUDE.md, GEMINI.md and REVIEW.md. It reads them “from the head branch (the branch with your changes), not the base branch”, so an instruction file merged to main after the branch was cut is not what reviewed the branch. The diagnostic for instruction files generally is Copilot ignoring your instructions?.

Budget and usage

For Business and Enterprise, “code review access is governed by budget controls. If a user reaches their user-level budget, or if the enterprise or cost center spending limit is exhausted, code reviews are blocked along with other AI credits-consuming features.” A review that stopped appearing on the 20th of the month, for everyone, with no configuration change, is worth checking against the organization’s budget page before anything else on this list.

GitHub’s estimate for what a review consumes: “$0.05 USD to $1 USD worth of AI credits with ‘Lite’ effort, and $0.25 USD to $5 USD worth of AI credits with ‘Balanced’ effort”, excluding Actions minutes, rising with pull request size and with the amount of custom instruction. Automatic review on every push of every large pull request is how a budget is exhausted by mid-month.

The checklist

Then, if a review did run: approvals are off by default; agentic context needs Actions; instruction files are read from the head branch.

A controlled reproduction

When the checklist does not settle it, reproduce in a way that removes the variables. This is what to do, not what has been done — nothing here was run against your repository.

1. Create a throwaway repository in the same organization, with one file. Create a branch ruleset on it: Active, target Include default branch, Automatically request Copilot code review ticked, drafts and new pushes off.
2. Open a pull request as yourself, non-draft, into the default branch, with a one-line change. If a review appears within a minute, the mechanism works for your account and organization; the difference between this repository and the real one is the cause. Compare the two rulesets line by line.
3. If nothing appears, press Request. If a manual review appears, the automatic trigger is the problem — re-read the ruleset’s enforcement and targeting. If nothing appears on request either, it is eligibility: plan or policy.
4. Then vary one thing at a time against the real repository: open the same change as a draft (should not review); mark ready (should review); push a commit (should not re-review); enable new pushes and push (should). Each step confirms one row of the checklist.

Illustrative — the shape of a minimal ruleset, as the repository settings UI presents it, not a file you can commit:

Ruleset: copilot-review-default
Enforcement status: Active
Target branches: Include default branch
Branch rules:
  [x] Automatically request Copilot code review
      [ ] Review new pushes
      [ ] Review draft pull requests

Frequently asked questions

Copilot reviewed the pull request once and now ignores every push. Is that a bug? No. One review per pull request is the documented default; Review new pushes changes it, at a cost per push. Request a re-review by hand when the diff has materially changed.

Can I make Copilot’s review required for merging? Not as a Comment review, which is the default. Copilot approvals (public preview) can be enabled and, separately, allowed to count toward merge requirements; an organization or enterprise policy can disable this everywhere. Whether an AI approval should satisfy a required-reviewer rule is a governance question the code review lesson takes up.

Can I request a review from a script or CI? Yes — the REST API accepts copilot-pull-request-reviewer[bot] as a requested reviewer, per GitHub’s how-to page. The same eligibility rules apply.

Does Copilot need GitHub Actions enabled to review at all? No. Actions powers the agentic capabilities; without it “reviews will still be generated” in a more limited form. You “do not need to have GitHub Actions enabled in your organization or enterprise to use the agentic capabilities”, but GitHub-hosted runners being disabled does remove them.

Why does the review appear on some repositories and not others? Almost always organization-ruleset targeting — an include or exclude pattern that does not match what you think — or a repository ruleset that exists in one repository and not the other. The organization ruleset page lists its current targets.

The review appeared, then vanished. A Copilot review is dismissed like any other when the reviewer’s approval is invalidated by new commits (approvals only), and a review’s comments can be resolved or hidden by people. Check the timeline; the review is usually still there under “hidden” or “resolved”.

Recap and next step

Eligibility first — plan and policy — because nothing downstream matters without them. Then the ruleset: Active, targeting the pull request’s base branch and this repository. Then the pull request itself: not a draft, not already reviewed before your last push, opened by someone with access, not from a fork. Then budget. If a review ran and disappointed, approvals are off by default, agentic context needs Actions, and instructions come from the head branch.

If you are enabling this for a team rather than fixing it for yourself, the automatic code review lesson is the setup walkthrough, Copilot code review vs human review is the policy question, and the seeded-defect corpus is how to find out what your configured review actually catches before you rely on it. For organizations writing the review policy down, the Enterprise Deployment Toolkit’s AI-assisted development policy and security checklist are the documents that decision ends up needing.