GitHub’s November 5–6, 2026 updates extend both control over Copilot code review and visibility into what happens after it comments. A separate public preview reorganizes the pull request overview. Together, the changes address a practical question: how can teams supervise growing volumes of assisted development?
Review policy becomes more programmable
The November 6 code-review release adds REST and GraphQL management of settings from enterprise policy down to repositories. Administrators retain their respective scopes, and lower levels cannot override enterprise-managed decisions. The APIs also expose attribution and available review metadata, helping clients distinguish Copilot’s output.
Authentication support differs by endpoint. GitHub says repository settings support GitHub Apps and fine-grained personal access tokens with appropriate Administration permissions, while the enterprise and organization settings endpoints do not support those credential types. Automation should follow the documented endpoint contract rather than reuse one broad token indiscriminately.
Addressed feedback is broader than accepted suggestions
The November 5 usage API adds counts for evaluated and addressed code-review comments. A developer may address feedback by applying it, editing independently, asking Copilot for a change, or replying that a later pull request will handle it. The ratio is therefore not simply the number of clicked suggestions.
Evaluation happens when a pull request merges, and the counts belong to that merge day. Breakdown fields include severity and review characteristics. The report also counts merges without a later human change request, which describes a workflow outcome rather than proving code correctness.
Usage visibility and interface changes
On November 6, the impact dashboard added Copilot Chat and the VS Code Agents window to feature engagement reporting. The former Passive users label becomes Chat-first users. GitHub says adoption-phase rules and cohort sizes do not change; the additional engagement signals should not be interpreted as a sudden jump in qualified adoption.
The November 5 pull request overview is an opt-in preview with a gradual rollout. It places readiness information near the top, adds conversation filters, and supports returning to the classic view. Available actions still depend on the user’s permissions.
Use the new numbers carefully
Our analysis is to write down a metric’s numerator, denominator, and event date before putting it on a management dashboard. A team that changes its merge frequency can change a daily addressed rate without changing review quality. Comparing counts before and after a reporting expansion also requires accounting for the additional signals.
Use representative pull requests to validate how an event appears in the report. Pair quantitative trends with a sample of actual findings: was the comment relevant, was the fix correct, and did the change survive later testing? Deferred work should remain visible in the team’s task system.
These updates improve the evidence available to engineering leaders. They work best as inputs to a review process with accountable owners, rather than as a substitute for testing or a single score that ranks developers.