Code review has always had two parts: the feedback and the sign-off. GitHub Copilot has been able to handle the first part for a while now, leaving comments, catching bugs, and flagging style issues on pull requests. The second part — the actual approval that clears a PR to merge — has stayed a human job. That changed this week.
GitHub announced that Copilot code review can now submit real approvals on pull requests, not just comments. When an organization turns the feature on, Copilot’s sign-off counts toward a repository’s required-approvals rule, just as a teammate’s approval would. It’s a small-sounding change with real weight: GitHub has moved Copilot from advisory to authoritative in the one place where code review actually gates what ships.
Here’s how it works. Every Copilot code review already ends with an overview comment. That comment now includes an approval assessment, Copilot’s read on whether the pull request looks ready to merge. On its own, that assessment doesn’t do anything. It’s a recommendation, not a decision. But administrators can flip a setting that lets Copilot turn that assessment into a formal, binding approval, the kind that satisfies branch protection rules and moves a PR toward merge.
The guardrails are worth walking through, because GitHub built in more caution here than the headline suggests. Approvals are off by default. Nobody wakes up tomorrow with Copilot suddenly approving code across every repo — an admin has to opt in first. That control sits at three levels: enterprise, organization, and repository, and each level can enable approvals outright, restrict them, or defer the decision down to the next level. Repository admins gain an added layer of precision: the ability to limit which file paths Copilot can approve. A team could let Copilot sign off on documentation and test fixtures, while keeping approval authority for anything that touches authentication or payment logic strictly human.
GitHub also carried over a behavior every developer already expects from human reviewers: push a new commit after approval, and that approval gets dismissed automatically. Copilot doesn’t get to rubber-stamp a PR once and walk away from whatever gets added later. It has to look again.
The rollout lands as a public preview across Copilot Pro, Pro+, Business, and Enterprise plans, so it’s already reaching a wide swath of GitHub’s paying users rather than sitting behind a narrow beta.
This didn’t come out of nowhere. GitHub has spent the past few weeks steadily widening what Copilot code review can touch. Late in August, the company removed the old 300-file, 20,000-line size cap on reviews and extended coverage to pull requests opened by bots and by Copilot’s own cloud agent. Approval authority is the logical next step in that sequence — GitHub has been building toward a version of Copilot that can operate inside the full pull request lifecycle, not just comment from the sidelines.
The bigger question for engineering leaders isn’t whether Copilot can spot a bug. It’s how much authority an organization is comfortable handing to a tool that doesn’t get fired, doesn’t sit in a retro, and doesn’t carry the same accountability a human reviewer does when something breaks in production. That’s not a knock on the technology. It’s just a different kind of decision than turning on a linter.
“Approval is where code review stops being advice and becomes authority, and GitHub just moved Copilot across that line,” said Mitch Ashley, vice president and practice lead for CIO & Technology Buyers, and Software Lifecycle Engineering at The Futurum Group. “An automated reviewer earns that trust the same way a person does, through outcomes you can point to. Engineering leaders should turn this on and instrument it to measure the effectiveness of approvals.”
That instrumentation is the part GitHub doesn’t hand you. If Copilot’s approvals start counting the same as a human’s, engineering leaders will want dashboards showing how often it approves correctly, how often a human catches something after the fact, and whether approval speed is coming at the cost of review depth. None of that tracking exists by default. Someone has to build it, and Ashley’s point is that it’s the only way an automated reviewer actually earns the authority GitHub just handed it.
Teams that adopt this well will probably start narrow. Approve Copilot for low-risk paths first — documentation, configuration, test code — and watch how it performs before expanding the scope. The file-path restriction GitHub built in makes that kind of staged rollout easy to do deliberately rather than by accident. Teams that skip that step and flip approvals on everywhere at once are trading a review bottleneck for a governance gap, and they may not notice the trade until an incident forces the conversation.
GitHub has been treating Copilot less like a bolt-on assistant and more like a member of the review pipeline with real permissions. Billing changes, expanded review scope, and now approval authority are all pieces of the same shift: AI code review is moving from a feature teams try to infrastructure teams depend on. The organizations that get the most out of it will be the ones that set the boundaries before Copilot does, not after.
