GitHub gave Copilot a formal vote on September 1. Administrators can now let its code review submit an approval that counts toward a repository’s required-approvals rule.[1]
That change lands beside a quieter July decision: Copilot code review reads custom instructions, agent instructions, and agent skills from the pull request’s head branch. The proposed change can therefore help define the context used to review the proposed change.[2]
I have written before about GitHub’s merge queue breaking the review-to-main contract and GitHub Actions growing a process model. The new development moves the trust boundary again. GitHub has turned an AI review from advice into merge authority while leaving part of the reviewer’s instruction surface inside the candidate branch.
an approval assessment became an approval
Every Copilot review now includes an approval assessment in its overview comment. That assessment reports whether Copilot considers the pull request ready, but it does not affect merge requirements. Formal approval is a separate administrator-controlled option.[1]
When all three administrative layers allow it, Copilot can submit an approving review that satisfies the ordinary required-approval rule. Enterprises can disable the capability or delegate the choice. Organizations can enable it everywhere, select repositories, or let repository administrators decide. A repository can enable approval and limit counted approvals to pull requests where every changed file matches one of as many as 15 configured globs.[1][2]
The feature is off by default and remains in public preview. New commits dismiss a Copilot approval, after which a fresh review can be requested.[1][2] Those are sensible restraints. They do not answer the independence problem created by the reviewer’s context.
GitHub’s interface makes the first two states look close because both appear in the pull-request review system. Their consequences differ sharply. Advice can be wrong without changing branch eligibility. A counted approval changes whether the repository considers a pull request mergeable.
the candidate branch supplies review context
GitHub’s current documentation says Copilot reads .github/copilot-instructions.md, path-specific instruction files, AGENTS.md, and relevant agent skills from the head branch rather than the base branch. GitHub presents this as a testing convenience: teams can change review instructions in a feature branch and see their effect before merging them.[2]
That is useful for developing a reviewer. It is a weak foundation for an independent gate.
A pull request can modify application code and modify instructions that shape how Copilot examines that application code in the same diff. Skills may add task-specific workflows. Repository MCP servers can supply context from issue trackers, service catalogs, documentation, and incident systems. GitHub says the GitHub and Playwright MCP servers are enabled by default for code review, and the repository setting that allows MCP tools during review is enabled by default.[2]
None of this proves a practical approval bypass. GitHub may apply hidden controls, model-level defenses, or policy layers beyond the published repository context. The public documentation does establish an architectural fact: review inputs can come from the candidate revision, while the output can become a counted approval.
The clean design would separate review customization from approval policy. Head-branch instructions could still produce a preview assessment. A counted approval should use instructions pinned to the protected base branch, an organization-owned policy revision, or an immutable ruleset reference. The approval record should identify which instruction commit, skills, MCP configuration, model family, effort level, and review trigger produced it.
Without that provenance, the green check records a result while hiding much of the evaluation environment. GitHub already says the product uses a tuned mix of models, prompts, and system behaviors and does not support model switching. Models used for review may differ from those enabled on an organization’s model settings page.[2] Administrators are buying a gate whose evaluator can change behind a vendor-managed product boundary.
closed loops already exist in public repositories
The surrounding ecosystem has already moved beyond the hypothetical stage. An August 2026 preprint linked AI-authored pull requests with AI-attributed review events from public GitHub data. It found 248,641 identifiable agent-authored pull requests with at least one AI-attributed review. Of those, 208,145 received same-product review and 45,269 received cross-product review, with overlap between the groups.[4]
The authors are careful about what those numbers mean. Their signatures produce lower-bound counts. A closed loop in the dataset means identifiable AI products appeared on both sides of a pull request; it does not prove humans were absent, the review was correct, or the pull request merged.[4]
A separate study of 33,596 agent-authored pull requests in popular repositories found that 61.38 percent had no recorded review activity. Among the reviewed subset, 58.77 percent had agent-only review, 10.14 percent had human-only review, and 31.09 percent mixed human and agent participation. The paper also warns that a maintainer may inspect a change without leaving a trace in the review record.[5]
Those caveats make the evidence useful rather than weak. Public GitHub history already contains abundant machine-on-machine review, but conventional review metadata cannot reliably tell us whether an accountable person evaluated the change. Counting Copilot approvals toward merge requirements gives that ambiguous record a stronger operational consequence.
GitHub expanded the loop on August 27, four days before launching approvals. Copilot review can now automatically examine pull requests authored by bots, including Copilot cloud agent, with the organization billed when no licensed account can absorb the usage. It also removed the previous limit of 300 files or 20,000 lines for a reviewed pull request.[3] The author, reviewer, review runner, approval event, branch rule, billing system, and repository host can now sit inside one vendor’s platform.
branch protection needs separation of duties
GitHub gives administrators enough switches to avoid the dumbest deployment. Keep Copilot approvals disabled at the enterprise boundary. If experimentation is required, select a disposable repository and restrict counted approvals to low-risk paths. Preserve status checks, CODEOWNERS review, merge queues, deployment controls, and a named human approval for production code.
File globs help, but they are a crude risk language. A documentation change can alter agent instructions. A test fixture can change what a reviewer sees as expected behavior. A dependency lockfile can change executable supply, yet GitHub excludes some dependency-management files from Copilot review.[2] Risk follows behavior and authority, not filename aesthetics.
The most defensible invariant is brutally simple: an AI-generated or AI-materially-modified change cannot satisfy its final independent review requirement with an approval from the same platform agent family. Cross-product review is still evidence, not accountability. A human with repository responsibility should own the last gate for sensitive paths.
Operator experience already shows how ruleset details leak into daily work. A long-running GitHub Community discussion documents teams accidentally blocking pushes to feature branches when automatic Copilot review was coupled to broad pull-request rules, plus gaps around programmatic re-review and reviewer visibility.[6] Adding approval authority increases the cost of ambiguous configuration. A bad switch now affects merge eligibility as well as comment traffic.
GitHub’s own documentation still says Copilot is not guaranteed to find every problem, can make mistakes, and should be supplemented with human review.[2] That warning sits awkwardly beside a feature designed to let the same system satisfy the approval count.
The machine can inspect code, gather context, run tools, and produce useful evidence. It can save human attention for architecture, product behavior, and risk. The review record should describe that contribution honestly. Calling it one required approval imports the social meaning of an accountable teammate into a vendor-operated inference event.
The approval button has become a software supply-chain primitive. GitHub has shipped the primitive before proving a clean separation between candidate-controlled context and evaluator-controlled policy. Administrators now own the missing boundary.
Sources
[1] https://github.blog/changelog/2026-09-01-copilot-code-review-can-now-approve-pull-requests | Copilot code review can now approve pull requests [2] https://docs.github.com/copilot/code-review | About GitHub Copilot code review [3] https://github.blog/changelog/2026-08-27-copilot-code-review-resolution-reasons-and-expanded-capabilities | Copilot code review expanded capabilities [4] https://arxiv.org/html/2608.21311v1 | AI-to-AI Code Reviews of GitHub Pull Requests [5] https://arxiv.org/html/2605.02273v1 | These Aren’t the Reviews You’re Looking For [6] https://github.com/orgs/community/discussions/160286 | Configuring automatic code review by Copilot discussion