Since 1 September a Copilot approval can satisfy GitHub's required-approvals rule

Set the enterprise switch, then the organisation one, and a Copilot review satisfies a required-approvals rule "the same way a teammate's approval would", according to GitHub's changelog ^[5]. Push a new commit and the approval is dismissed exactly as a human's would be, and the review can be re-requested ^[6]. On a repository whose rule is one approval, the whole path is: author pushes, Copilot approves, merge ^[21].

The settings live on three separate pages ^[19]. At enterprise level the path is AI controls > Available Agents > Copilot code review, then Allow Copilot to approve pull requests ^[11]. At organisation level it is Settings > Copilot > Code review > Approvals > Count Copilot approvals toward merge requirements ^[12]. At repository level it is Settings > Copilot > Code review > Auto-approval ^[13]. The repository level splits the question in two, so Copilot can post an Approve review that shows in the timeline without that review satisfying branch protection ^[14].

Approvals are not configured in rulesets. Automatic review is, as the rule Automatically request Copilot code review with sub-options Review new pushes and Review draft pull requests ^[15], exposed in the REST rulesets API as rule type `copilot_code_review` with parameters `review_on_push` and `review_draft_pull_requests` ^[16]. A CI job that diffs ruleset JSON can therefore tell you whether review is requested on every push and cannot tell you whether the resulting approval counts toward the merge requirement ^[15].

GitHub's figures for the 11 September ensemble are 47% more addressed comments per review for high severity findings, 31% for medium, 11% for low, and about 8% less review cost ^[10]. The high-severity gain is roughly four times the low-severity one ^[18], so the number that transfers to your repositories depends on the severity mix of findings you actually get, at the Lite effort level GitHub tested ^[9]. The metric counts comments marked addressed, and the resolution reasons that produce that label (Addressed, Won't fix, Incorrect) shipped two weeks earlier, on 27 August, alongside the removal of the 300 file and 20,000 line cap ^[8]. The same 11 September release also let Copilot resolve its own comments when a later commit addresses them ^[9]. The changelog does not say whether those self-resolutions count as addressed ^[9].

The dev.to post that catalogues the settings said, "This is the moment where AI code review stops being a suggestion layer and becomes part of the control plane" ^[17]. I would draw the line more narrowly. The merge semantics change only where the organisation setting Count Copilot approvals toward merge requirements is on ^[12], and GitHub is explicit in the same release that "An approval assessment alone does not count toward merge requirements" ^[4]. Until August, a Copilot review left only a Comment and the documentation said it did not count toward required approvals ^[1]. Copilot approvals are a public preview, and GitHub's docs say they are "subject to change" ^[7].