Copilot can now approve a pull request, if an administrator lets it

GitHub shipped two Copilot changes on September 1, 2026, and one of them moves a decision that used to belong to a person. Copilot code review can now submit an approval on a pull request, and that approval counts toward the repository's required-approvals rule. The feature is off unless an administrator turns it on, which is the part worth reading twice before anyone does.

What the approval actually does

There are two separate things here, and the changelog keeps them apart. The first is the approval assessment: every Copilot code review now carries, in its overview comment, a signal for whether Copilot considers the pull request ready to approve. GitHub is explicit that this assessment on its own does not count toward merge requirements. It is a read on the model's judgment, surfaced next to the detailed comments.

The second is the approval itself. When an administrator enables it, Copilot submits a review approval that behaves like anyone else's. It counts toward the required-approvals rule, and it is dismissed as soon as new commits are pushed, exactly as a human reviewer's approval would be. A fresh review can then be requested to get a new one. The feature is in public preview on the Copilot Pro, Pro+, Max, Business and Enterprise plans.

Who decides, and at which level

Control sits with administrators at three levels, and the repository level is the one with real granularity.

• Enterprise administrators can leave approvals off across the whole enterprise, or let each organization decide.
• Organization administrators can turn approvals on for the whole organization, delegate the decision to repository administrators, enable it for named repositories, or switch it off.
• Repository administrators turn approvals on or off, and choose which file paths Copilot is allowed to approve.
• The path restriction is the useful lever: generated files, lock files and documentation can be opened to Copilot while application code stays with people.

Budgets can now expire on their own

The second change is smaller and lands on billing. An individual user budget can now carry an optional expiration date, and GitHub removes the budget on that date. The user then falls back to the next budget that applies to them, which is their cost center per-user budget or otherwise the universal budget. GitHub says the point is to stop the manual cleanup that temporary overrides used to require at scale.

The choices when creating or editing a budget are no expiration, which stays the default, expiration at the start of the next billing cycle, or expiration on a specific date in UTC. An expiration can be changed or cleared at any time, and it can be set in the billing settings or through the expires_at field in the Budgets REST API. This one is generally available, on the Copilot Business and Copilot Enterprise plans.

What to weigh before enabling it

The required-approvals rule exists to guarantee that at least one person other than the author looked at a change. Once Copilot can satisfy that rule, the guarantee changes shape: on a repository that requires a single approval, a change can now merge without any person having read it. This suggests the path restriction is not an optional refinement but the main safety control in the feature.

The dismissal behavior helps more than it first appears. Because an approval evaporates when new commits arrive, an author cannot collect a Copilot approval early and then push whatever they like. Anyone enabling this on a shared repository should decide in advance which paths are eligible, and treat the approval assessment, which changes nothing on its own, as the default setting for everything else.