Copilot adds review settings APIs: Verify policy and tool access

A script can save Copilot's repository review settings while the organization still has code review disabled. On November 6, 2026, GitHub added APIs for code-review settings and explicit review attribution. The new controls make a fleet rollout easier, but a successful settings write answers only part of the security question.

Before changing a repository, find out which organization or enterprise policy governs it. Check the tool access in a fresh review and save the reviewed commit. Approval counting needs its own decision.

This guide derives its procedure from GitHub's documentation and published API schema. We have not exercised it in a customer tenant. The coding-agent security baseline covers the wider deployment.

Choose credentials for each scope#

The release covers Copilot Pro, Pro+, Max, Business, and Enterprise plans, subject to the administrator role and scope involved. Its credential requirements differ across the hierarchy: an App credential that works for a repository is not a fleet-wide administration credential.

The table summarizes the read side of GitHub's published REST schema. Endpoint suffixes below are relative to https://api.github.com.

The enterprise and organization endpoints do not support GitHub App tokens or fine-grained personal access tokens. Keep the broader collector credential separate from the repository writer and from exported evidence. Review exports have their own permission requirement: supported fine-grained credentials need Pull requests read, not merely Administration read.

Save policy before tuning reviews#

At organization scope, retain configured_state, effective_state, editable, and managed_by. GitHub's policy reference distinguishes the stored organization choice from the result after enterprise policy applies. Use the effective state when checking whether the organization permits review; keep the stored choice to explain inheritance.

For a hypothetical pilot, suppose a repository owner wants to disable MCP context in code reviews while preserving it for the coding agent. First capture the repository baseline with an approved, already authenticated GitHub CLI session. Replace OWNER and REPO. This example reads settings and writes a local evidence file; it does not change GitHub policy.

Code source: illustrative collector using GitHub's published code-review settings schema.

A failed command can leave a partial file. Only a run that reaches the timestamp has completed this collection. Save the organization and enterprise responses alongside it using their authorized collectors; sequential reads are not an atomic policy snapshot.

Keep the runner's configured_by value. The runner reference identifies whether code review uses its own configuration or inherits the coding agent's configuration. Record labels, runner group, and repository-customization permission before changing it. An inherited runner deserves review even when nobody has explicitly configured a code-review runner.

Also retain configured and effective effort plus available_review_efforts. The effective repository value is a fallback used when the requester and pull request do not select an effort. It is not proof of the effort a particular review used. The effort reference also permits a null configured value when a stored effort is unavailable, so null alone does not establish the administrator's original intent.

Change the review-specific MCP switch#

GitHub shares repository MCP configuration between the cloud agent and code review. Its MCP configuration guide provides a separate switch for reviews. Disabling it prevents code review from calling MCP tools, including the default GitHub and Playwright servers, while leaving the shared configuration available to the cloud agent.

For the pilot, the minimal repository PATCH body is below. It is a proposed change for an authorized administrator, not a command run during this research. Omitted settings remain unchanged.

Code source: GitHub's repository settings PATCH schema.

Send that body to /repos/{owner}/{repo}/copilot/code-review/settings only after reviewing the baseline and intended scope. Read settings again and compare the entire response with the baseline. Request a fresh review on a harmless pilot change, then inspect its linked session logs. GitHub documents those logs as the place to check which MCP servers and tools started and were called. Do not infer that changing the switch cancels an already-running review; the cited contract does not establish that behavior.

An inherited policy conflict should stop the rollout. For REST organization writes, GitHub's schema documents 409 with POLICY_MANAGED_BY_ENTERPRISE for a locked policy and SETTING_NOT_EDITABLE for a locked setting. Repeatedly retrying the same write will not resolve the governing policy. With GraphQL, inspect both top-level errors and the mutation's conflict field; a returned response is not enough to declare success.

Keep the UI-only controls in the rollout record. Maximum effort, billing, and approval controls are outside these APIs. Automatic-review triggers also need their own check. A repository settings response cannot establish that a new pull request will receive a review or that a human must approve its merge. Use the human-review checklist for approval counting.

Export the review without overstating provenance#

The November 6 release adds explicit Copilot attribution. The REST schema names is_copilot_code_review on reviews and review comments, copilot_code_review_effort on reviews, and copilot_code_review_sources on review comments. Preserve these fields instead of identifying Copilot solely by bot authorship or parsing its prose.

For the pilot pull request, export both collections. These read-only commands require gh and jq, with an authorized identity that can read the pull request. Replace all placeholders and store the resulting private files under your evidence-retention policy.

Code source: illustrative export using GitHub's list reviews and list review comments endpoints.

The export preserves full records and pagination. Join comments to their review using pull_request_review_id, and retain review IDs, commit IDs, and timestamps. Check the review against the current pull request head before using it in a decision. If either collection fails, treat the directory as incomplete.

GitHub's source schema describes the comment-source array as potentially incomplete, with at most 16 entries. Entries identify skills, MCP sources, or custom instructions; a repository-relative path may be present, but source commit OIDs are not exposed. Issue timeline events do not carry these fields.

Use those sources to locate the records an investigation needs. An empty list cannot prove that no MCP tool ran, and a path alone cannot identify the instruction revision. Preserve the reviewed repository state and inspect session or downstream service records for a particular tool call. Keep missing effort metadata unknown instead of substituting the configured default.

Close the rollout with the pilot evidence#

Before expanding the change, attach the before-and-after settings, governing organization policy, runner origin, and the fresh review's commit and session link. The MCP-disabled pilot should show the switch off and no MCP calls in that new review's available session evidence. Record any inaccessible evidence as unresolved.

Prepare rollback from the settings you deliberately changed. Restoring the original MCP boolean is a different operation from replaying the full GET response, which contains derived fields. If changing review effort, preserve whether the intended setting was explicit or inherited; the API uses inherit to clear an explicit effort.

Record approval counting and automatic triggers alongside the pilot results. Expand only after the reviewer can account for the effective policy, intended MCP access, and evidence gaps for the pilot commit.