GitHub Copilot Code Review Gets API Controls: What Teams Should Automate

Before we dive in, why not take a quick peek at my portfolio: https://priyalraj.com

📋 TL;DR: What You’ll Learn Here

• New control surface: automate settings management, beyond requesting individual reviews.

• Permission boundaries: repo credentials don’t establish org-wide access.

• Useful first automation: read current settings, compare expectations, report differences.

• Rollout proof: verify effective config & actual review behavior before expanding.

📰 What Changed on November 6

GitHub Blog’s November 6 announcement adds REST & GraphQL management of Copilot code review settings across enterprise, org & repo scopes. Requesting reviews through REST already existed; this release expands administrative control.

Also new: explicit Copilot attribution, review-effort metadata when available, & reported skills, MCP servers & instructions behind comments. Review overviews group excluded files together. These changes cover Pro, Pro+, Max, Business & Enterprise plans.

My interest: replacing mystery settings with inspectable decisions. Team can discuss why repo uses particular review setup before somebody changes it during deadline pressure.

Think building thermostat. Reading temperature, choosing room setting & controlling building-wide limits are separate jobs. One working button doesn’t mean every control belongs to same person.

🔑 Auth Scope Changes Automation Design

Enterprise & org settings endpoints, including org runner settings, don’t support GitHub Apps or fine-grained personal access tokens. Repo endpoints support both, requiring Administration: read for reads or Administration: write for updates. Classic tokens require repo administrator access. Enterprise-managed settings cannot be overridden by org admins. See release permissions.

Warning: Do not broaden a token’s permissions merely to make an audit script succeed. Confirm supported credential type, intended scope, and responsible administrator before changing access.

Design read-only inventory first. Separate permission failure from config difference. Report neither as successful compliance check.

For client work, record which account owns each credential. Personal access during development doesn’t prove scheduled job has equivalent access. Test job identity separately before handing automation over.

🧭 Map Controls Before Writing Changes

Configuration docs distinguish scope: enterprise enablement policy; org enablement, default effort & runner config; repo effort, custom instructions & MCP usage. Maximum effort, billing & approvals aren’t available through this settings API.

That boundary matters when writing automation ticket. “Make review config consistent” sounds small but can hide decisions across unrelated controls. Name exact setting & intended repos before code exists.

Suggested inventory columns: repo owner, intended review setup, observed setup, policy owner, inspection time & unresolved issue. Keep credentials out. Existing issue tracker or small checked-in policy file usually suffices.

Start with repos whose owners can explain intended behavior. Unknown ownership creates ambiguous differences: drift, deliberate exception, or forgotten experiment? Script cannot settle that alone.

My tip: Require reason beside every exception. “Client repo uses separate review process” helps future maintainer; unexplained boolean invites accidental cleanup.

🔍 Read Config Before Enforcing It

GitHub’s GraphQL Copilot reference exposes availableReviewEfforts, customInstructionsEnabled, mcpEnabled & reviewEffort. Effort includes configured & effective values. Repo settings tune reviews; they don’t enable code review.

That gives useful distinction for audit: what owner stored versus what review would use. Inherited value deserves different treatment from accidental local override.

The repository schema exposes repositoryCopilotCodeReviewSettings with repo administration access. Following example reads one repo using GitHub CLI’s GraphQL support. Run with authenticated account permitted to inspect target repo; replace owner & name.

# terminal, read one repository's settings
gh api graphql \
  -f owner='YOUR_ORG' \
  -f name='YOUR_REPO' \
  -f query='
    query($owner: String!, $name: String!) {
      repository(owner: $owner, name: $name) {
        repositoryCopilotCodeReviewSettings {
          availableReviewEfforts
          customInstructionsEnabled
          mcpEnabled
          reviewEffort {
            configured
            effective
          }
        }
      }
    }
  '

Example performs query, without mutation. It isn’t full compliance scanner. Check returned errors, missing data & target identity before interpreting fields. Save output only through approved storage process.

Avoid adding write operation while debugging read access. First prove command addresses intended repo & receives meaningful data. Then decide whether observed setting needs changing.

📝 Turn Audit Into Reviewable Proposal

Suggested workflow: inspect, compare, propose, review, apply, inspect again. Each stage answers separate question. Did lookup work? Is difference unwanted? Who authorizes correction? Did change take effect?

Plain report template:

# copilot-review-audit.txt
Repository:
Inspection identity:
Inspection time:
Expected setting and reason:
Observed configured value:
Observed effective value:
Inherited policy owner:
Proposed change:
Reviewer:
Verification result:
Unresolved errors:

Keep proposal narrow. Changing effort, enabling additional tools & altering shared instructions together creates several explanations for later behavior. One setting per trial makes investigation easier.

If inherited policy explains difference, contact policy owner through existing team process. Avoid repeated writes attempting to defeat intended hierarchy. Record blocked change as blocked.

🎛️ Pick Effort From Evidence

Avoid universal rule that highest effort belongs everywhere. Review workload varies: typo fix, dependency change & cross-service auth change need different human attention too.

My evaluation set would include known defect, clean change & subtle edge case. Preserve starting commit & review instructions. Compare whether findings help reviewer make correct decision.

Measure useful findings, false alarms, missing known issues, review time & available usage evidence. Count corrections required before accepting suggested fix. Output length alone tells little.

Choose completion condition before trial. “Reviews look better” invites endless tuning. “Known defect identified with accurate file reference, clean change avoids invented blocker” produces assessable result.

🧩 Instructions & MCP Need Their Own Review

MCP connects tools to model workflows. Enabling tool usage introduces another dependency: which server provides context, who maintains it, & what happens when it fails?

Before changing repo setting, inventory intended servers & instruction files. Verify ownership & relevance. More context isn’t automatic improvement when context is stale or unrelated.

Use small test PR to examine actual review. Does finding cite relevant convention? Can human follow source to correct file? Does recommended fix preserve project behavior?

Treat reported sources as investigation aids. Source label alone doesn’t prove model followed every instruction correctly. Check claim against actual source & diff.

For repo guidance, keep rules concrete: auth boundary, expected validation & modules requiring special review. See my guide to repo instruction files for context organization.

✅ Roll Out Without Hiding Failures

Suggested first deployment: scheduled read-only report for few owned repos. Compare results manually before increasing coverage. Fix confusing labels while audience stays small.

For later writes, preserve prior values & planned restoration process. Re-read current state before applying reviewed proposal. Someone else can change settings between inspection & execution.

✅ Distinguish unsupported credential, denied access & unwanted config.

✅ Verify intended repo before interpreting output.

✅ Keep inherited policy owner visible in report.

❌ Replace unknown values with guessed defaults.

❌ Treat successful update response as proof of useful review behavior.

❌ Expand automation scope because another control appears nearby.

After rollout, inspect representative PR with repo maintainer. Confirm automation delivers understandable evidence & clear ownership. Retire report sections nobody can act on. Keep errors visible until resolved.

Final Thoughts

Copilot code review API controls make settings inspectable & manageable. Useful first automation: explain current state, ownership & differences before applying changes.

Keep auth scope explicit, preserve inherited controls, test one adjustment & verify resulting review. Small report with trustworthy evidence beats large script whose green status hides unknowns.

If you enjoyed this article, please make sure to follow me on Twitter.