GitHub Lets Copilot Code Review Be Managed Through REST and GraphQL APIs and Makes the Review Overview More Compact: Enterprise, Organization and Repository Settings Can Be Read and Changed, but Enterprise and Organization Endpoints Reject GitHub Apps and Fine-Grained Tokens and Maximum Effort, Billing and Approvals Stay Outside the API

On November 6, 2026, GitHub published a changelog entry called Copilot code review: API management and review overview updates. It says Copilot code review settings can now be managed through the REST and GraphQL APIs, from enterprise policy down to single repositories, and that the overview comment Copilot posts on a pull request is now more compact. The post says the updates are available to Copilot Pro, Pro+, Max, Business and Enterprise plans. It does not say whether any part is a preview, and it gives no pricing change. This is a vendor changelog, and we have not tested the endpoints.

Before this change, the REST API already let a developer request a review, choose its effort level and read information back. The post adds three things. First, explicit attribution fields identify Copilot's reviews and comments. Second, a response shows the review effort a review used, when that metadata is available. Third, it lists which skills, MCP servers and custom instructions Copilot reported as the sources for a comment. The wording "reported as" matters: these fields describe what Copilot says it used, and the post does not claim a way to verify it. For teams that audit AI review comments, these fields help separate Copilot's output from human comments and show what shaped a finding.

The settings part follows the three levels of GitHub administration. Enterprise administrators can enable or disable code review for all organizations, or leave the choice to organization administrators. Organization administrators can manage enablement, the default review effort and the runner configuration, but cannot override a setting that the enterprise manages. Repository administrators can manage review effort and whether reviews use custom instructions and MCP tools. The REST API accepts the same effort levels as the web interface, and the settings responses list the levels available to the caller. In the GitHub documentation the levels are Lite, a standard review, Balanced, which looks deeper at complex logic, security-sensitive code and cross-service changes and is the built-in default, and Max, which uses several high-reasoning models for the most intensive review.

The post gives a warning about authentication that is easy to miss. The enterprise and organization settings endpoints, including the organization runner endpoint, do not support GitHub Apps or fine-grained personal access tokens. The repository settings endpoints support both, with the Administration read permission to read settings and the Administration write permission to update them. Classic personal access tokens need repository administrator access. So an automation built as a GitHub App can manage repositories but not organization or enterprise policy. The documentation also says that other settings on the configuration page, such as maximum review effort, billing and approvals, are not available through the API.

The review overview comment changes too. New overviews keep findings together at the top. The review effort used and any surveys move to a compact footer. Skipped files and files excluded for content reasons share one section called Files not reviewed, with file names and linked reasons. Empty sections are left out, and long lists show an overflow count. A thumbs-down on an overview now lets a user add a reason, such as an approval assessment they disagree with, a comment that is too verbose or findings that are incorrect or nitpicky.

Other improvements include AI credits consumed shown in Copilot code review agent sessions, a bypass list for the Automatically request Copilot code review repository rule so exempt actors do not receive an automatic review, collapsed and then hidden findings that are unrelated to recent changes on later reviews of the same pull request, and Balanced effort reviews that now use three reviewer models with another model combining their findings. Bug fixes preserve billing and preview settings when code review is turned off and on, retry a failed or timed-out review once and switch to another eligible model when the preferred one is unavailable, let GitHub Actions, Dependabot and organization-owned apps request reviews on bot-authored pull requests again when the setting that blocks reviews requested with an external Copilot license is on and the organization pays, and stop false failure reports right after a review starts.

The GitHub documentation adds a rule about automatic reviews. A pull request can qualify from several independent sources, namely a user's own settings, repository rulesets and organization rulesets. They are evaluated separately, Copilot still posts a single review, and a user's settings cannot switch off push or draft reviews that a ruleset has turned on.

Our reading: the useful part for administrators is policy as code. Teams can now script enterprise, organization and repository settings and attribute comments, instead of clicking through pages. The limits are clear. The authentication rule blocks GitHub App automation for the top two levels, key controls stay outside the API, the source fields are self-reported by Copilot, and the post gives no numbers on review quality. Plan on testing the endpoints on a small repository first.