What the Copilot code review settings API means for you

GitHub now lets you read and change Copilot code review settings through its REST and GraphQL APIs. This works at every level, from enterprise policy down to a single repository, according to GitHub’s changelog. The same update makes Copilot’s review overview comment more compact. It also fixes problems with billing, automatic reviews, and reliability.

One detail decides whether you can use the new API: which kind of token you use. According to GitHub, the enterprise and organization settings endpoints don’t accept GitHub Apps or fine-grained personal access tokens. The repository endpoints do accept both.

The background you need

Copilot code review is GitHub’s AI reviewer for pull requests. You add Copilot to a pull request the way you would add a human reviewer. It reads the changes, leaves comments, and posts an overview comment that sums up what it found. Based on the feedback options GitHub describes, that overview can include an approval assessment, meaning Copilot’s view of whether the change looks ready to merge.

Effort level controls how much work Copilot puts into a review. GitHub says you could already pick it through the REST API when you requested a review.

The settings hierarchy. GitHub accounts nest in three layers:

• A repository holds one codebase.
• An organization groups many repositories under one team or company.
• An enterprise groups several organizations, usually for a large company that wants central policy and billing.

Settings made at a higher layer can limit what lower layers are allowed to choose.

An office building is a useful comparison. The building manager (enterprise) sets rules for every floor. Each floor’s tenant (organization) sets rules for its own rooms. Each room (repository) can then adjust what is left. The comparison breaks down in one way: in a building, the person with the master key can usually open every door. On GitHub, as you will see below, the credential that can open a room is not necessarily allowed into the manager’s office.

REST and GraphQL are two styles of API that GitHub offers:

• REST gives you fixed URLs per resource, and you send standard HTTP requests to them.
• GraphQL gives you one endpoint, and you write a query asking for exactly the fields you want.

GitHub says both now support code review settings.

Tokens are how a script proves who it is. Three kinds matter here:

• A classic personal access token (PAT) is the older type. It is tied to your user account and grants broad scopes.
• A fine-grained personal access token is the newer type. You limit it to specific repositories and specific permissions, such as Administration.
• A GitHub App is an installed integration with its own identity, separate from any person.

GitHub has steered teams toward fine-grained tokens and Apps for automation, because they limit access more tightly and do not depend on one employee’s account. That is why the token rules in this update matter.

What actually changed

Some of this was already possible. According to GitHub, you could already do three things through the REST API:

• request a Copilot review
• choose the review’s effort level
• get review information back

The new part is settings management. Depending on your role, you can now read and update code review settings through REST and GraphQL, at the enterprise, organization, and repository levels. Before this, scripting those settings was not part of the API story the changelog describes.

Two details help if you write tooling:

• The REST API accepts the same effort levels as the web interface.
• Organization and repository settings responses list the effort levels available to you. Your script can ask what is allowed instead of guessing.

The credential rules are the part to read slowly:

• Enterprise and organization endpoints, including an organization runner endpoint, do not support GitHub Apps or fine-grained personal access tokens.
• Repository endpoints support both. They need Administration: read to read settings and Administration: write to change them.
• Classic personal access tokens need repository administrator access.

There are also changes outside the API:

• The overview comment is more compact.
• You can now explain a thumbs-down on an overview. After you give it a 👎, choose Add a reason and pick the main problem. The options include an approval assessment you 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.
• The update includes fixes for billing, automatic reviews, and reliability. The changelog does not describe them.

GitHub lists the updates as available on the Copilot Pro, Pro+, Max, Business, and Enterprise plans.

What it means for developers who don’t read every release note

If you only use Copilot review by clicking buttons on pull requests, little changes for you. The shorter overview and the feedback reasons are the parts you will notice.

If you maintain automation, the token rules shape what you can build.

If your tooling runs as a GitHub App or a fine-grained token, you can manage Copilot review settings repository by repository today, as long as it has Administration permission. Many platform teams already run a bot that sets up new repositories with branch protection, labels, and similar defaults. That bot can now apply Copilot review settings to each repository too.

If you want to set policy once at the organization or enterprise level, that same bot cannot do it. The changelog states which credentials are excluded. It does not state which ones are accepted. Before you plan around a particular credential, read GitHub’s guide, Configuring Copilot code review with the API, which the changelog links.

If you use classic tokens for repository settings, the person who owns the token needs repository administrator access. A token from someone with ordinary write access will not be enough.

A practical habit follows from the effort-level detail. Read the list of available levels from the settings response rather than hardcoding names into your script. Then your script keeps working if the options differ between organizations or change later.

Watch two things next: whether GitHub extends App and fine-grained token support to the higher-level endpoints, and what the setup guide says about credentials for those endpoints.

What we don’t know yet

• Credentials for higher levels. The changelog says which credentials the enterprise and organization endpoints reject. It does not say which they accept, or whether App support is planned.
• The runner endpoint. The changelog mentions an organization runner endpoint but does not explain what it controls.
• The fixes. GitHub does not say what was wrong with billing, automatic reviews, or reliability, or who was affected.
• What compact means. The changelog does not show how the new overview differs from the old one.
• Why effort levels vary. Settings responses list the levels available to you, which suggests availability can differ. The changelog does not say what causes the difference.