GitHub updated Copilot code review on November 6, 2026 with new API access to settings and review metadata, a shorter review overview and several reliability fixes. The change is useful to teams that need to know whether an AI review ran, what it examined and which controls apply across repositories. GitHub lists Copilot Pro, Pro+, Max, Business and Enterprise as eligible plans. These are GitHub's stated capabilities; VIBPS has not configured or tested them in a repository.
What can administrators manage through the API?
GitHub says enterprise administrators can enable or disable Copilot code review across organizations or leave the choice to each organization. Organization administrators can control review availability, the default effort and runner configuration. Repository administrators can set review effort and decide whether custom instructions and MCP tools are used. A lower-level setting cannot override a policy set above it. The REST API accepts the same effort levels as the web interface and responses identify which levels are available to the caller.
The authentication detail matters for anyone automating setup. GitHub says its enterprise and organization settings endpoints do not support GitHub Apps or fine-grained personal access tokens, while repository settings endpoints support both with Administration read or write permission as appropriate. A classic token requires repository administrator access. An automation that can inspect repository settings therefore should not be assumed to have the same reach at organization or enterprise scope. Check the current API documentation before building an administrative workflow.
Can an app identify what Copilot reviewed?
The updated review data adds explicit attribution for Copilot reviews and comments. GitHub says it can report the effort used when metadata is available, along with skills, MCP servers and custom instructions that Copilot reported as sources for a comment. That gives a review dashboard more context than a plain comment body. It does not prove that every relevant file was examined or that a finding is correct. Makers still need the code diff, test results and human judgment to decide whether a change is ready to ship.
How did the review overview change?
New review overviews move the effort level and surveys to a footer and put skipped or excluded files in one Files not reviewed section with reasons. Empty sections disappear, and long lists show an overflow count. GitHub also added a way to provide a reason after negative feedback on an overview. Several related fixes address billing settings, automatic review retries and incorrect failure reports. A compact summary can make gaps easier to notice, but it should not hide the underlying review details from someone making a release decision.
The release follows GitHub's separate November 5 public preview of a redesigned pull request Overview page. That page helps a reviewer find merge readiness and discussion; the November 6 change concerns Copilot's review controls and output. These are different layers of the same code review workflow. For an app maker, the practical next step is to check who can request reviews, which files were excluded, and how a finding relates to the latest code change before merging.