Copilot code review can now be switched on or off by API, from enterprise down to repo

GitHub, which is owned by Microsoft, says Copilot code review settings can now be managed through the REST and GraphQL APIs, from enterprise policy down to single repositories. The update also shrinks the review overview comment and adds billing and reliability fixes.

Three admin levels get their own controls

The changelog says the update is available on the Copilot Pro, Pro+, Max, Business and Enterprise plans. Reviews could already be requested through the REST API, with a chosen effort level, and results read back. Two additions are new on the read side: explicit attribution fields that identify Copilot’s reviews and comments, and the review effort a review used, when that metadata exists. The API can also show which skills, MCP servers and custom instructions Copilot reported as sources for a comment.

Write access depends on role. Enterprise administrators can turn code review on or off for every organization, or leave the decision to organization administrators. Organization administrators can manage enablement, the default review effort and the runner configuration. Repository administrators can set review effort and whether reviews use custom instructions and MCP tools. Anything an enterprise manages cannot be overridden below it, according to GitHub.

The REST API accepts the same effort levels as the web interface, and settings responses list the levels available to the caller. There is a catch in authentication. The enterprise and organization endpoints, including the organization runner endpoint, do not support GitHub Apps or fine-grained personal access tokens. The repository endpoints do, with Administration: read to read settings and Administration: write to update them. Classic personal access tokens need repository administrator access.

A shorter overview and a way to say why it missed

New review overviews keep findings at the top. Review effort and any surveys move into a compact footer. Skipped files and files excluded by content rules now share one “Files not reviewed” section, listing filenames with linked reasons. Empty sections are dropped and long lists show an overflow count.

Users can also explain a thumbs-down. After a 👎, an Add a reason option lets them pick the main problem, such as an approval assessment they disagree with, a comment that is too verbose, or findings that are incorrect or nitpicky. GitHub says it uses this feedback to improve Copilot’s findings.

Smaller changes include AI credits shown inside Copilot code review agent sessions, and support for the bypass list in the repository rule that automatically requests Copilot review, so listed actors get no automatic review. When a pull request is reviewed again, comments that have nothing to do with the latest commits are first folded away and later dropped from view. In Balanced effort mode, three separate models now do the reviewing and a further model merges what they found.

Fixes that touch billing and retries

Several fixes matter for teams that run this at scale. Turning code review off and later back on no longer wipes billing and preview configuration. A review that errors out or runs too long now gets one automatic second attempt, and Copilot may fall back to a different qualifying model if its first choice is down. Reviews that are mid-flight during a service update are given extra time, and a review no longer flags a bogus failure moments after it begins and then throws its output away.

GitHub Actions, Dependabot and apps owned by an organization or enterprise can again request reviews on bot-authored pull requests when the block on reviews requested with an external Copilot license is on, provided the organization pays for the review. Surveys no longer appear if an organization has opted out of feedback collection.

Governance becomes scriptable, and measurable

The practical shift is that review policy can now be applied and audited in code instead of clicked through settings pages in each organization. For a company with hundreds of repositories, that is the difference between a policy and a hope. The locked-down enterprise tier also gives security teams a way to keep a setting fixed. The token limits, however, mean automation of enterprise and organization settings needs a classic personal access token or similar, since GitHub Apps are not supported there.

The settings API arrives alongside reporting. A GitHub changelog dated November 5 describes a new copilot_code_review object in usage metrics, which counts comments evaluated and comments addressed, and also merged pull requests where nobody requested changes after Copilot’s first review. According to that changelog, comments are counted on the day the pull request merges, and Copilot usually does not evaluate comments on bot-opened pull requests. Access requires the View Copilot Metrics permission and the usage metrics policy enabled. An earlier Aiholics report on the usage API’s split of own-key traffic described the same permission model.

Admins can thus set rules, observe what happens and, through the new thumbs-down reasons, feed complaints back to GitHub. Claims about better findings, such as the three-model Balanced mode, are GitHub’s own and the changelog gives no accuracy figures. It also does not say how many AI credits a review consumes or whether the retry counts against them. Related coverage: Copilot’s impact dashboard now counts chat users.