GitHub announced on September 1, 2026 that Copilot code review can now approve pull requests. The feature is in public preview, off by default, and can be controlled at enterprise, organization, and repository levels. When an administrator enables it, a Copilot approval can count toward a repository’s required-approvals rule.
For QA engineers and automation testers, this changes a release-control boundary. It does not mean an AI review makes a change safe to merge; it means teams need a deliberate test plan before allowing an AI approval to satisfy any merge requirement.
What GitHub changed
- Every Copilot review now includes an approval assessment in its overview comment.
- That assessment alone does not satisfy a merge rule.
- Administrators can opt in to let Copilot submit an approving review that can count toward required approvals.
- New commits dismiss a Copilot approval, matching the behavior of a human approval.
- Repository administrators can restrict which file paths are eligible for approvals that count toward merge requirements.
GitHub’s configuration documentation says repositories can use up to 15 file globs for this scope. An approval only counts when every changed file matches one of those globs. That makes path scoping especially useful for low-risk, well-tested areas, while keeping migrations, authentication, payments, production configuration, and test infrastructure under human-only review.
Why this matters for QA engineers
Approval rules are a quality gate, not a convenience setting. If a team turns on AI approvals without measuring review quality, a plausible but incomplete review can become part of the evidence used to merge. QA should therefore help define both the safe initial scope and the proof needed to expand it.
- Coverage risk: confirm the review notices defects that matter to your product, not only style issues.
- Rule correctness: verify an AI approval counts only where policy intends it to.
- Freshness: test that a post-approval commit dismisses the approval and triggers a new review.
- Auditability: ensure reviewers can distinguish Copilot’s approval, comments, changed files, and human decision.
- Fail-safe behavior: validate that unsupported paths, failed reviews, and unavailable Copilot access cannot accidentally satisfy the gate.
A controlled rollout checklist
- Start with a pilot repository. Keep the feature off globally. Pick a non-production codebase with stable CI, clear ownership, and representative pull requests.
- Use explicit allowlist paths. Begin with narrow, low-risk paths such as internal documentation or isolated test fixtures. Exclude security-sensitive code, CI workflows, release scripts, dependency manifests, and test helpers until separately evaluated.
- Keep human approval required. During the pilot, do not make Copilot the only approval that can merge a pull request. Compare its findings and approvals with independent human review.
- Build a seeded defect set. Create test pull requests containing known issues: missing assertions, flaky waits, authorization gaps, unsafe configuration changes, broken error handling, and misleading comments. Track detection rate and false positives.
- Test branch-rule behavior. Confirm that an eligible-path pull request can receive an approval, while a PR containing one excluded file cannot use that approval toward the merge requirement.
- Test commit invalidation. After an approval, push a meaningful code change and verify the approval is dismissed. Request a fresh review and record the timeline.
- Review the evidence monthly. Sample merged PRs, compare AI comments with escaped defects and human findings, and rollback the policy if the quality signal degrades.
Suggested acceptance cases
| Case | Expected result |
|---|---|
| Feature disabled by default | Copilot may assess readiness but cannot submit a merge-counting approval. |
| Allowed files only | Copilot approval can count only after the configured policy is enabled. |
| One excluded file added | The approval must not count toward merge requirements. |
| New commit after approval | The Copilot approval is dismissed and a fresh review is required. |
| Known defect PR | Copilot’s output is recorded; a human reviewer still verifies the defect and merge decision. |
| Service outage or review failure | No stale or absent AI result can be treated as an approval. |
Bottom line
Copilot approvals can be useful evidence in a mature pull-request workflow, but they should not become invisible automation. Start narrow, preserve human accountability, test the rule mechanics, and use real defect data to decide whether the AI signal is trustworthy enough for any merge gate.
Sources: GitHub Changelog: Copilot code review can now approve pull requests (September 1, 2026) and GitHub Docs: Configuring code review by GitHub Copilot, accessed September 2, 2026.