A team that turned on GitHub Copilot code review six months ago and never looked at the settings again is running a weaker product than the one shipping today. Three changelog entries landed this September, on the 11th, 18th, and 23rd, and together they change what the reviewer does, how it reports back, and who controls its default behavior across an org. None of it is a breaking change. All of it is worth an admin's attention before the next sprint.
What changed in GitHub Copilot code review this September
Auto-resolution and deeper analysis (Sept 11)
Copilot now closes its own loop. When a developer pushes a commit that addresses a Copilot code review comment, Copilot resolves that comment during its next rereview, according to GitHub's September 11 changelog entry. That same update pulled the review agent's tooling up a level: analysis now runs on the full set of shell tools from the Copilot SDK, not a narrower review-specific toolset. The Lite effort level changed architecture too, moving from a single agent working alone to an ensemble of agents producing the review.
Resolution reasons, grouped findings, drafted commit messages (Sept 18)
A week later, GitHub refreshed how the review overview reads. Findings now sort into three groups: open, resolved since the last review, and previously missed, per GitHub's September 18 changelog entry. Auto-resolved comments now carry a reason, either Won't Fix or Incorrect, based on the developer's subsequent commits. Auto-resolution got smarter about not overriding a human: if a developer replies to keep a comment open, Copilot honors that and leaves it open, closing only the comments nobody pushed back on between reviews. The same update added commit-message drafting. Accept a batch of suggestions and Copilot generates a relevant commit title and an optional description based on the changes it just approved.
A real admin control for default effort, on every plan (Sept 23)
The most consequential change for anyone running Copilot at org scale shipped September 23. GitHub added a dedicated personal settings page for automatic review and default review effort, plus a separate, enterprise-wide default review-effort setting for organization-owned repos, per GitHub's September 23 changelog entry. The enterprise setting takes Lite, Balanced, or GitHub's own default, and it applies across every repo the org owns instead of leaving each repo on whatever it inherited. Both features are now generally available, and personal configuration expanded to every paid Copilot plan, including Business and Enterprise, where it was previously restricted to Pro, Pro+, and Max.
Before September 23, an org either accepted GitHub's default effort level everywhere or standardized it by hand, repo by repo. One setting now cascades to the whole org.
How to configure GitHub Copilot code review for a team
1. Enable the org policy and decide who gets it
GitHub's current documentation is explicit about the gating step: nobody in the org gets Copilot code review until an admin flips it on in the Copilot policy settings, per GitHub's code review concepts page. Availability runs across Pro, Pro+, Business, and Enterprise plans, and on Business or Enterprise an admin can extend access to unlicensed org members as well, so the decision isn't limited to who already holds a Copilot seat.
2. Set an enterprise-wide default review effort
With the September 23 setting live, pick Lite, Balanced, or GitHub's default at the enterprise level rather than leaving new repos to inherit whatever GitHub ships by default. Lite now runs on an ensemble of agents rather than a single agent. Decide this centrally once, and every org-owned repo starts from the same baseline instead of drifting repo by repo.
3. Write repo-wide custom instructions in .github/copilot-instructions.md
Repo-wide review guidance lives in a single file, .github/copilot-instructions.md, according to GitHub's guide to using Copilot code review. Use it to tell Copilot what the team actually cares about: naming conventions, which patterns are banned, which dependencies need a second look. This is the fastest way to cut noise from a review that otherwise flags style choices the team already settled.
4. Scope path-specific instructions where the repo-wide file isn't precise enough
A monorepo with different rules per package needs more than one instruction file. GitHub supports path-specific instruction files under .github/instructions/**/*.instructions.md, so a frontend package and a backend service can carry different review guidance inside the same repo. Reach for this once the repo-wide file starts contradicting itself across directories, not before.
5. Decide auto-review triggers at the repo level
A review can run on request or automatically, and automatic review is configured through a ruleset rather than a global toggle. Decide, per repo, whether Copilot reviews every new PR, every push to an existing PR, or holds off on drafts until they're marked ready. A repo with a high volume of small, iterative pushes is a different call than a repo where PRs open already close to done.
6. Set approval requirements
Nothing in Copilot code review requires a human sign-off out of the box; per the same GitHub documentation, that setting sits at zero by default and can be turned on at the enterprise, organization, or repository level. If a team wants a person's approval on record before a PR merges, that's a choice someone has to make, not a default GitHub ships.
What GitHub Copilot code review costs to run
The meter runs on two separate tracks, according to GitHub's models and pricing reference: tokens spent on the review itself draw from AI credits, while the agent's shell-tool work, the analysis steps that read the diff and run checks, draws from GitHub Actions minutes. GitHub doesn't disclose which model runs a given review, which means per-review cost isn't something you can predict from the docs alone; it shows up on the bill after the fact rather than in a rate card up front.
That billing split is separate from the seat-pricing change landing this quarter. GitHub's new billing rules cover the October 1 move to upfront seat charges and, in the same piece, the August 28 default-effort change from Lite to Balanced taking effect no earlier than September 28. The September 23 setting covered above is what lets an admin override that default deliberately instead of letting it flip on GitHub's timeline.
What Copilot code review should not replace
GitHub says this about its own product, plainly, in the limitation notes on its code review docs: Copilot is not guaranteed to spot all problems or issues in a pull request, and sometimes it will make mistakes. That page tells teams to always validate Copilot's feedback carefully and supplement it with a human review. Take it as the working rule for everything Copilot's review agent now does.
The resolution-reason feature from September 18 is the clearest example of why. When Copilot marks a comment Incorrect instead of Won't Fix, that's Copilot's own judgment call on a human's code, made during a rereview, and it stands unless someone replies to keep the comment open. A team that trusts every auto-resolution without spot-checking is trusting an AI's self-assessment of its own accuracy, which is exactly the kind of call GitHub's own docs say still needs a human eye.
The pattern isn't unique to Copilot. GitLab's Duo permissions default draws the same line in a different tool: read-only actions run without friction, but anything that writes or deletes defaults to requiring approval first, giving a reviewer a checkpoint before an agent changes something on its own. Copilot code review sits in a comparable spot. It reads and summarizes; it doesn't merge code or touch production. Under the NCSC's human-in-the-loop, on-the-loop, out-of-the-loop framework, an agent that reads and summarizes can run on-the-loop, watched but not gated on every step. That's the right posture for Copilot's review comments generally. Auto-resolution decisions specifically warrant closer, in-the-loop attention, because that's the one place the agent is judging its own work rather than flagging someone else's.
None of this argues against turning the feature on. It argues for deciding, deliberately, which parts of the workflow get a spot-check and which don't, the same decision GitHub's deny, ask, allow permissions for Copilot agents asks an admin to make for agent operations elsewhere on the same settings screen.
FAQ
Does GitHub Copilot code review replace human code review?
No, and GitHub says so directly in its own documentation: Copilot is not guaranteed to spot all problems in a pull request, and teams should validate its feedback and supplement it with a human review. Copilot code review is a first pass that catches routine issues and drafts context faster than a person starting cold, not a substitute for a reviewer signing off on a merge.
What plans include GitHub Copilot code review?
Pro and Pro+ include it for individual users. On Business and Enterprise, an organization must enable the Copilot code review option in its Copilot policy settings before members can use it, and an admin can also grant access to unlicensed org members. Personal configuration, the settings page for automatic review and default effort, became available on every paid plan as of the September 23 update; it used to be limited to Pro, Pro+, and Max.
How much does a Copilot code review cost to run?
It's billed two ways: token consumption comes out of AI credits, and the agentic infrastructure running the review, the shell-tool analysis steps, consumes GitHub Actions minutes. GitHub doesn't publish which model handles a given review, so there's no fixed per-review rate to plan against; the cost shows up on the bill rather than in a published rate card.
What changed in Copilot code review in September 2026?
Three updates. September 11 added auto-resolution on rereview and expanded the review agent's tooling to the full Copilot SDK shell toolset. September 18 grouped findings into open, resolved since last review, and previously missed, added resolution reasons (Won't Fix or Incorrect), made auto-resolution respect a human's reply to keep a comment open, and added commit-message drafting when accepting suggestions. September 23 added a personal settings page for automatic review and default effort, an enterprise-wide default effort setting for org-owned repos, and expanded personal configuration to every paid Copilot plan.