Copilot Approval Is a Revocable Machine Attestation

GitHub changed Copilot code review from an adviser into a participant in merge control on 1 September. Every Copilot review now includes an approval assessment. Administrators can also let Copilot submit an approving review and, through a separate setting, let that approval satisfy a repository's required-approval rule.

Four days earlier, GitHub expanded the population and size of work Copilot can review. Automatic review can now cover bot-authored and Copilot cloud agent pull requests, and the previous 300-file or 20,000-line review limit no longer applies. Reviewers can also close a Copilot comment with one of three reasons: Addressed, Won't fix, or Incorrect.

Those releases create an attractive loop: an agent writes a pull request, Copilot reviews it, findings are resolved, and Copilot approves it. The loop is useful, but each step makes a different claim. An approval assessment is model output. A submitted approval is pull-request state. A resolved conversation is a human disposition. A required approval is one branch rule. Passing all of them still does not establish file ownership, complete review coverage, successful tests, or permission to merge a high-consequence change.

The repeated angle to avoid

The ten most recent posts here covered cache representation layers, product-variant graphs, htmx state provenance, Shopify finance clocks, verified-bot policy joins, AI-catalog conformance, security-dashboard denominators, chat-adapter semantics, agent compute planes, and security treatment states. Older overlapping posts already covered Copilot review runners and context exclusions, testable review environments, skills and MCP context, review effort levels, security review receipts, and review outcomes.

The weak version would revive the old X needs Y formula: AI approvals need human oversight. It would also repeat the generic instruction to configure branch protection and CODEOWNERS.

The narrower thesis is that approval eligibility and review coverage are now separate sets. GitHub can decide that a Copilot approval counts because every changed path matches an administrator's globs. Copilot can still omit a supported path's particular file because some file classes are excluded from review, an agentic setup failed, the relevant business invariant lives outside the repository, or the model simply missed the issue. Meanwhile, the review can use instructions from the pull request's head branch, although code ownership is resolved from the base branch.

That difference is the information surplus. The safe unit is not approved=true. It is an attestation envelope containing the reviewed commit, changed-path set, eligible-path rule, observed coverage gaps, review context, effort level, findings, human ownership, required checks, and invalidation conditions.

Fresh evidence and background serve different jobs

Source	Freshness	What it contributes
Copilot code review can approve pull requests	1 September 2026	Approval assessments, submitted approvals, default-off controls, path scoping, required-approval participation, and dismissal after a new commit
Resolution reasons and expanded capabilities	27 August 2026	Full agentic review for Copilot-authored pull requests, organization-billed review for eligible bot-authored work, removal of prior PR-size limits, and comment-resolution reasons
Configuring Copilot code review	Current primary documentation	Separate toggles for submitting and counting approvals, enterprise and organization policy layers, effort levels, and the all-changed-files path rule
About Copilot code review	Current primary documentation	Excluded file classes, head-branch instructions, review triggers, fallback when agentic capabilities fail, costs, approval behaviour, and the requirement to validate with human review
Protected branches	Background platform contract	Diff snapshots, stale approval dismissal, latest-push approval, required conversations, status checks, code-owner reviews, bypasses, and merge queues
CODEOWNERS	Background platform contract	Base-branch ownership, pattern semantics, syntax failures, required owner approval, and protection of the ownership file itself

The two changelog entries are fresh primary evidence of the changed operating surface. The documentation explains current mechanics and limitations. It does not prove that Copilot will find every defect; GitHub explicitly says it is not guaranteed to spot every issue and recommends supplementing its feedback with human review.

One review now produces three approval states

“Copilot approved this” is ambiguous. The product exposes three states with different consequences.

State	Where it appears	Merge effect	Appropriate interpretation
Approval assessment	Copilot's overview comment on every review	None by itself	Copilot's current judgment that the PR appears ready or not ready
Approving review	Pull-request review state when approval submission is enabled	Visible approval, but may still not satisfy a requirement	A machine reviewer attested to the observed change under current settings
Counting approval	Branch-rule calculation when counting is also enabled	Can satisfy one required-approval slot	Repository policy accepts that machine attestation for this eligible PR

The separation is valuable. A team can observe assessment quality without changing merge state. It can then allow submitted approvals while keeping them non-counting. Only after measuring misses and false approvals does it need to consider whether a Copilot review can satisfy one merge requirement.

Do not collapse those stages in analytics. Record whether Copilot said “ready,” whether it submitted an approval, whether policy counted that approval, and whether the PR ultimately merged. Otherwise a dashboard cannot distinguish model calibration from repository authority.

The two approval controls also prevent a false binary choice. A repository does not have to choose between ignoring Copilot and letting it unlock main. It can keep the visible attestation while preserving all required human approvals.

Path eligibility is universal, not additive

At repository level, GitHub lets an administrator enter up to 15 file globs for counting Copilot approvals. The important rule is universal:

A Copilot approval counts only when every changed file matches at least one configured glob.

That is safer than allowing a low-risk path to contribute one approval to a mixed-risk pull request. Consider this policy:

content/**
docs/**
tests/fixtures/public/**

A pull request changing only content/help/returns.md can be eligible. A pull request changing that file and src/checkout/calculate-total.ts should not be. The checkout file fails the all-files test, so Copilot's approval cannot count.

This creates a useful monotonic property: adding an ineligible file removes machine-approval eligibility rather than expanding it.

There are still three sharp edges.

First, leaving the path list blank allows approvals to count for all paths. Blank is not a neutral trial setting; it is the broadest policy.

Second, glob coverage is only as good as the repository map. A generated configuration under content/, a deploy script in docs/tools/, or an executable fixture can carry more consequence than its directory name suggests. Classify paths by effect, not by whether they look like prose.

Third, path eligibility is evaluated against changed filenames, not business impact. A tiny shared schema file can alter checkout, booking, lead routing, analytics, and customer messaging without living under any of those feature directories.

For a first rollout, use a positive allowlist for genuinely low-consequence changes. Do not try to enumerate every dangerous path in a denylist.

Eligible does not mean reviewed

The path rule answers whether an approval may count. It does not prove that Copilot examined every byte matched by the rule.

GitHub's current Copilot review documentation names file types excluded from review, including dependency-management files such as package.json and Gemfile.lock, log files, and SVG files. It also says reviews continue in a more limited form if the Actions workflows used for agentic capabilities fail; full project context and tool-backed analysis may then be absent.

A large PR no longer exceeds the old 300-file or 20,000-line product limit, but removal of a hard limit is not a completeness guarantee. It means the request is accepted for review, not that attention, context, and evidence scale without loss.

Keep four sets distinct:

C = every file changed by the pull request
E = changed files eligible under approval-counting globs
R = changed files and hunks Copilot could review with the available context
H = changed files requiring human or code-owner judgment

A counting approval requires at least:

C = E

A responsible merge policy additionally asks whether material files are represented in R, and whether every file in H has the required human approval. GitHub does not expose those as one equality test, so the team must use conservative path policy, required checks, CODEOWNERS, and sampling to close the gap.

A practical coverage check should fail or require human review when the PR includes:

• a file class documented as excluded from Copilot review;
• binary, generated, vendored, minified, or unusually large material;
• policy instructions that influence the review itself;
• ownership, workflow, ruleset, deployment, or secret-handling configuration;
• schema or shared-library changes with effects outside the path name;
• external behaviour that cannot be reconstructed from repository context;
• an agentic-review fallback, missing setup step, or unavailable external context.

Do not infer coverage from the absence of comments. A clean review can mean clean code, a missed defect, an excluded file, unavailable context, or a policy that never asked the relevant question.

The proposed branch can influence its own reviewer

Copilot code review reads repository instructions and agent skills from the pull request's head branch. That supports useful experimentation: a team can change a review skill and test it in the same PR.

Once Copilot can submit a counting approval, the same mechanism creates a self-reference:

pull request changes review instruction
  -> Copilot reads proposed instruction
  -> proposed instruction shapes review
  -> Copilot may approve the pull request containing that instruction

The problem is not that every instruction change is hostile. An ordinary wording edit can unintentionally remove a security check, narrow a path rule, suppress a warning, or point the reviewer at stale external context. The approval would then be partly justified by policy that has not yet been accepted on the base branch.

CODEOWNERS provides a useful counterweight because review requests use the ownership file on the pull request's base branch. Protect these paths with human owners and exclude them from counting Copilot approvals:

/.github/CODEOWNERS
/.github/copilot-instructions.md
/.github/instructions/**
/.github/skills/**
/.github/workflows/copilot-code-review.yml
/AGENTS.md
/REVIEW.md
/CLAUDE.md
/GEMINI.md

Also make the approved owner responsible for .github/CODEOWNERS itself. GitHub's documentation recommends protecting the ownership file or its containing directory; otherwise a pull request can weaken who must approve the next change.

This is not an argument against head-branch review instructions. It is an argument for separating testability from authority. Let Copilot test proposed policy, but let base-branch ownership decide who may adopt it.

Comment resolution is disposition, not revalidation

The new Addressed, Won't fix, and Incorrect reasons make review feedback more legible. They can help GitHub improve the product and help a team distinguish accepted fixes from rejected findings.

They do not mean the same thing:

Resolution	Human claim	Evidence still needed
Addressed	The author or reviewer believes the concern was changed	The new commit actually removes the issue without introducing a regression
Won't fix	The concern is understood but not being changed	Named risk owner, reason, scope, expiry or follow-up where consequence warrants it
Incorrect	The finding does not apply	Reproduction, type or data-flow evidence, test, or domain explanation

A branch can require all conversations to be resolved before merge. That rule proves that no required conversation remains open; it does not prove every resolution was correct. A contributor can resolve a valid finding as Incorrect, or mark it Addressed before the follow-up commit passes tests.

Keep the finding disposition and the approval attestation separate. When a commit addresses a comment, request a fresh review. For high-risk paths, require the human owner to confirm the evidence even if Copilot reapproves.

The useful metric is not “resolution rate.” Track findings by resolution reason, later reappearance, reviewer overturn, and escaped defect. A high Incorrect rate may reveal noisy review policy. A high Addressed rate followed by repeated regressions may reveal weak validation rather than strong AI review.

Commit freshness is part of the approval

GitHub says a Copilot approval is dismissed when a new commit is pushed, after which a fresh Copilot review can be requested. That is the right default because an approval describes the diff it observed, not the permanent identity of the pull request.

There is another source of change: the base branch. A pull request can acquire a different effective diff when main moves, when the branch is updated, or when the merge base changes. Protected-branch settings can dismiss stale approvals when the recorded diff state changes. GitHub also offers a rule requiring approval of the most recent reviewable push by someone other than the pusher, and merge queues can test the change against a current merge group.

Use distinct freshness controls:

Change	Evidence to refresh
New commit on the PR branch	Copilot review and approval; affected human review where required
Base branch or merge base changes	Strict status checks or merge-queue checks; stale approval handling
Review instruction or skill changes	Human owner approval using base-branch ownership
Required check configuration changes	Ruleset owner review and audit of expected check source
Finding marked addressed	Test or reproduction plus a review of the new commit

An approval timestamp alone is insufficient. Record the head SHA and, for high-assurance workflows, the base or merge-group SHA against which required checks ran.

Avoid a reapproval storm by matching policy to consequence. Dismissing every human approval after every generated snapshot update may be expensive. Requiring the latest reviewable push can be a workable compromise for ordinary changes. For payment, authentication, permission, migration, deployment, or customer-data paths, stale-review dismissal and current merge-queue evidence are usually worth the extra run.

Bot-written and bot-approved are independent dimensions

The 27 August release lets automatic Copilot review cover pull requests authored by bots, including full agentic review for Copilot cloud agent PRs. This closes a practical gap: automation-generated changes no longer need to miss the normal Copilot review path merely because no licensed human authored the PR.

It also creates a tempting but misleading phrase: “independent AI review.” Separate bot identities do not guarantee independent evidence. The author and reviewer may still share:

• repository instructions from the same head branch;
• the same incomplete tests or fixtures;
• the same missing external business context;
• model-family blind spots or generated-code conventions;
• an administrator's over-broad path and approval policy;
• a common failure to understand production state.

Independence should be designed by evidence source, not vendor label. A useful control stack might combine:

1. an agent-authored change;
2. Copilot's diff and repository-context review;
3. deterministic lint, type, unit, security, accessibility, or schema checks;
4. an integration or browser test against a representative environment;
5. code-owner judgment for the affected business surface;
6. a merge-queue run against current base state.

Two models agreeing on a plausible diff are weaker than one model plus a failing deterministic test that exposes the real defect.

An approval envelope makes the claim inspectable

GitHub manages the actual review state. A team can keep a compact sidecar record in check output, an internal audit event, or a deployment system without copying source code or model reasoning.

copilot_approval_envelope:
  repository: example/storefront
  pull_request: 842
  observed_revision:
    head_sha: 9b72c1e
    base_branch: main
    base_sha_for_required_checks: 410cd88
  authorship:
    pull_request_actor: copilot-cloud-agent
    author_class: bot
  copilot_review:
    run_id: review_1842
    effort: balanced
    agentic_context: available
    instructions_source: head_branch
    assessment: ready_to_approve
    submitted_review: approve
    submitted_at: recorded_timestamp
  approval_policy:
    submission_enabled: true
    counts_toward_requirement: true
    eligible_globs_revision: approval-policy-7
    every_changed_file_eligible: true
  coverage:
    changed_file_count: measured_by_platform
    excluded_file_classes_present: false
    policy_files_changed: false
    external_context_required: false
    known_gaps: []
  findings:
    addressed: 2
    wont_fix: 0
    incorrect: 1
    unresolved: 0
  independent_gates:
    required_code_owner_review: passed
    status_checks: passed
    merge_queue: pending
  invalidate_on:
    - head_sha_change
    - effective_diff_change
    - review_policy_change
    - required_check_failure

The field values are an implementation sketch, not GitHub's event schema. The important property is scope. The record says which revision was assessed, whether the approval counted, what eligibility rule applied, and which independent gates remained.

Do not store hidden chain-of-thought or sensitive repository excerpts. Decision metadata, check identifiers, revisions, and explicit gaps are enough to make the merge explainable.

A staged rollout for counting machine approvals

Use four stages rather than one enablement switch.

Stage 0: assessment only

Keep submitted approvals disabled. Collect the assessment from the overview comment and compare it with human review, CI, later fixes, and escaped defects.

Measure false-ready cases, not just agreement. A model that agrees with humans on easy documentation PRs but misses one checkout regression should not be promoted by its overall agreement percentage.

Stage 1: visible, non-counting approvals

Allow Copilot to submit approving reviews, but leave “count toward merge requirements” off. This tests lifecycle behaviour: notifications, stale dismissal, re-review after pushes, finding resolution, audit events, and developer interpretation.

Confirm that people do not treat a visible green approval as permission to bypass required owners or checks.

Stage 2: counting approval on a narrow lane

Choose low-consequence paths where every changed file can be positively allowlisted and independently validated. Examples might include reviewed public documentation, isolated examples, or generated snapshots whose source and deterministic verification live elsewhere.

Keep at least one human or code-owner approval if the content carries legal, pricing, security, accessibility, SEO, or customer-facing risk. Machine approval should remove repetitive review work, not erase accountable ownership.

Stage 3: evidence-based expansion or deliberate stop

After a fixed evaluation period, review:

• false approvals and missed defects by path class;
• excluded or unreviewable files encountered;
• how often limited review ran after agentic setup failure;
• reapproval frequency after commits and base updates;
• finding-resolution reasons and later reversals;
• human review time saved versus attention spent on false positives;
• incidents or rollbacks on machine-approved changes.

Expand one path class at a time. Keeping AI approval non-counting on revenue, authentication, deployment, privacy, or data-migration code can be the successful end state, not a failed rollout.

Failure modes worth rehearsing

Blank path configuration becomes universal authority

A team enables counting approvals for a trial but leaves file paths blank. Copilot approval can now satisfy the rule across the repository. Start with a positive low-risk allowlist and test a mixed-path PR that must remain ineligible.

Every path matches, but one file is excluded from review

The approval globs include the whole changed set, while a dependency file, log, SVG, binary, or other unsupported material receives no useful review. Add a coverage check that routes excluded or opaque classes to human owners and deterministic tooling.

A PR weakens the instructions used to approve itself

The branch changes AGENTS.md or a Copilot skill, removing a required security or analytics check. Copilot reads the proposed head-branch policy and approves under the weaker rule. Exclude review-policy files from machine-counting lanes and require base-branch code owners.

Addressed closes the conversation before the fix is proven

A comment is resolved, the conversation requirement turns green, and a new commit changes behaviour without a focused test. Bind resolution to the fixing commit, rerun the relevant fixture, and request fresh review.

Removal of the large-PR limit is reported as complete coverage

A generated or cross-service PR with hundreds of files receives an approval, so the team assumes the former hard limit has become exhaustive review. Split changes by business boundary where possible and require deterministic evidence for every affected service and schema.

Bot author and AI reviewer share the same blind spot

Copilot cloud agent creates a patch based on stale documentation; Copilot code review reads the same documentation and approves it. Add an independent test, current system readback, or accountable owner whose evidence does not come from the same context chain.

The head is unchanged, but the base moved

The Copilot approval remains associated with the PR while the effective merge result changes because main advanced. Use stale-diff protection, strict checks, or a merge queue so current-base evidence—not an old green review—controls mergeability.

Required approval becomes the only gate anyone notices

Copilot satisfies one approval slot, while status checks, code-owner requirements, unresolved risks, or deployment evidence are absent or bypassed by an administrator. Apply no-bypass rules where appropriate and inspect merge-requirement composition, not only the final green button.

The practical conclusion

GitHub's new approval feature is more than a stronger review comment. It lets model output participate in repository authorization. The product wisely separates assessment, approval submission, and approval counting; dismisses Copilot approval after new commits; and lets administrators require that every changed path fit a counting lane.

Those controls are necessary, but they answer only eligibility and lifecycle. They do not make path matching equivalent to review coverage. They do not turn a resolved comment into a verified fix. They do not prevent a proposed instruction from shaping its own review. They do not replace base-branch code ownership, current-base testing, or accountable judgment on consequential changes.

Start with assessments. Then test visible non-counting approvals. If the evidence is strong, allow counting only for positively selected low-risk paths and keep a coverage check for excluded, opaque, policy, shared, or externally dependent files. Bind the attestation to the head SHA, refresh it when the effective diff changes, and preserve independent owners and deterministic gates.

That turns Copilot approval into something useful and accurately named: a revocable machine attestation inside a larger merge proof, not the proof by itself.