GitHub opens Copilot Code Review management via API at three levels

When a company has dozens of organizations and hundreds of repositories, configuring AI review by hand quickly turns into a lottery. In one project Copilot checks every pull request, in another it is disabled, and in a third it uses an MCP server the security team knows nothing about. GitHub has closed this gap: Copilot Code Review settings can now be managed through the REST and GraphQL APIs at three levels: enterprise, organization, and individual repository.

The practical upshot is simple: review policy can be stored as code, checked automatically, and rolled out across the entire environment at once. The update is available on the Copilot Pro, Pro+, Max, Business, and Enterprise plans.

How the settings hierarchy works

The enterprise administrator decides whether Copilot Code Review is allowed in all organizations or whether each organization chooses for itself. If a setting is locked at the top, it cannot be overridden below.

At the organization level, you can enable review, set the default thoroughness level, and manage the runner configuration. The repository administrator gets a narrower set of levers: choosing the thoroughness of the review and allowing or forbidding the use of custom instructions and MCP tools.

Imagine a company with fifty repositories. The security team bans external MCP servers, the platform team enables a balanced review mode by default, and the owners of critical services choose a deeper review. Previously, such a scheme had to be maintained through the interface and internal memos. Now it can be described in a script, the desired state can be compared with the actual one, and discrepancies can be fixed through the API.

What you can now get from the API

GitHub has added explicit fields that distinguish Copilot's reviews and comments from messages by people and other apps. The API can also return the thoroughness level used and indicate which skills, MCP servers, and custom instructions Copilot named as the sources of a specific finding.

This matters more than it seems. A team can automatically collect AI review findings, calculate the share of accepted recommendations, and investigate a disputed comment: was it the result of the standard model, an internal instruction, or a connected tool? Agent sessions now also show the number of AI credits spent, so the cost of a review can be weighed against its value.

The review summary itself has become more compact. Skipped and excluded files are gathered in one section with the reasons for exclusion, empty blocks are hidden, and long lists are collapsed. When giving negative feedback, users can specify a reason: incorrect conclusion, excessive verbosity, or a nitpicky comment.

Limitations and practical takeaway

The API has one unpleasant detail. The enterprise and organization settings endpoints, including runner configuration, do not support GitHub Apps or fine-grained personal access tokens. For repository management both options work: reading requires Administration: read, and changing requires Administration: write. A classic personal access token needs administrative access to the repository.

GitHub has also fixed operational issues: a failed or stuck review is automatically retried once, and if the selected model is unavailable, the system can switch to another suitable one. Billing and preview feature settings are preserved after review is turned off and on again.

For a platform team, the next step is obvious: export the current settings via the API, define a reference policy, and add a drift check to the existing GitHub management pipeline. But don't hand a script write permissions right away. First run a read-only audit, check policy inheritance separately, and only then automate changes. The API makes Copilot Code Review manageable, but the quality of its findings still needs to be measured on your own repositories.