GitHub Copilot Code Review Now Tracks Open, Resolved and Missed Findings

September 18 update: Copilot review now keeps a clearer issue ledger

GitHub has made a redesigned Copilot code-review overview generally available. The overview now separates findings into Open, Resolved since last review and Previously missed. Each item includes severity and a link to the relevant inline comment, while the overview retains the review effort level and the pull request assessment.

The Previously missed group deserves attention. It covers issues that were already present in the change but appeared only in a later Copilot review. That is useful evidence about review variance. It also means a clean first pass should not be treated as proof that the pull request was issue-free.

Copilot now gives review comments short titles and handles resolution state with more context. If a developer replies that an issue should stay open, Copilot is meant to preserve it. Later commits can close a comment with a reason such as Won't Fix or Incorrect. Teams should sample those automated resolutions during rollout because a tidy overview can still hide a mistaken closure.

Batch acceptance also gets generated commit titles and optional descriptions based on the selected changes. The convenience is real, but the resulting message still needs to describe the intent of the human-approved patch. Review the diff, not the fluency of the message.

Read GitHub’s improved Copilot code-review announcement.

Update checked September 18, 2026. Feature status and behavior come from GitHub. Governance advice is MustHave.ai analysis. Marker: copilot-review-ledger-20260918.

Update, August 29, 2026: Balanced becomes the default as retention expands

GitHub has now attached review effort to a larger September 28 policy migration. Copilot code review will default to Balanced unless an organization explicitly selects Lite. On the same date, GitHub says its unified agent and chat policy will be enabled by default for existing Business and Enterprise customers, and Copilot Chat conversations will move from 28-day retention to the life of the user’s account.

The setting is therefore no longer only a review-depth dial. It belongs in an administrative change record with repository scope, retention, user notice and policy ownership. GitHub also announced upfront seat billing for affected card and PayPal customers and says revoked seats will not be refunded for the remaining period. Read our separate Copilot billing, retention and policy checklist for the September 1, September 28 and October 1 dates.

Update, August 12, 2026: GitHub adds per-model token reporting

GitHub’s usage report can now break out input, output, cache-read, and cache-write tokens by model, alongside AI credits. The view is available to Business and Enterprise administrators and to individual users.

Metric	Useful question	Common misread
Input tokens	How much context are workflows sending?	More context means better answers
Output tokens	Which models generate the most material?	More output means more productivity
Cache read/write	Are repeated contexts being reused efficiently?	A high cache rate proves low total cost
AI credits	Which models consume the allowance?	Low credits mean low review burden

This makes the article’s warning more actionable: do not turn usage into a performance grade. Join the report to pull-request cycle time, accepted changes, defects, reverts, and reviewer hours. Read GitHub’s per-model token reporting announcement.

GitHub just gave engineering leaders two controls they have been missing: a dial for how deeply Copilot reviews a pull request, and a counter for which coding agents people actually use.

The releases arrived together on August 7. GitHub Copilot review effort now has Lite and Balanced levels, while the Copilot usage metrics API can break out activity from third-party agents. One changes the work. The other makes adoption visible.

That pairing matters more than either changelog item alone. Teams can spend more inference on the repositories where review depth is valuable, keep routine changes lighter, and then check whether Claude, Codex, or another integrated agent is actually earning a place in the workflow.

Lite and Balanced are policy choices, not quality grades

An organization can set a default and a repository can override it. The selected effort level appears in the pull-request timeline or review comment, which gives reviewers a visible record of what kind of automated pass ran.

Do not read Balanced as "approved" or Lite as "careless." GitHub’s own documentation says Copilot can miss problems and make mistakes. Human review, tests, code scanning, and repository-specific instructions still carry the decision.

The new metric counts agent activity without inventing impact

The second release adds an optional totals_by_3rd_party_agent array to aggregated organization and enterprise reports. Each recognized agent can include a stable agent_id, a display name, a count of user-initiated interactions, and a session count.

What the agent fields can and cannot tell you

Field	Useful for	Does not prove
agent_id	Joining the same agent across reporting windows.	That two differently named agents are technically equivalent.
agent_name	Human-readable dashboards and adoption reports.	A stable key; names can change.
user_initiated_interaction_count	Seeing deliberate user engagement.	Completed work, accepted code, or quality.
session_count	Comparing repeat use at aggregate level.	Business value or developer time saved.

There are important edges. GitHub says per-user entries omit session_count, unrecognized agents are omitted, and nested interaction counts should not be added to an equivalent top-level field. A dashboard that ignores those notes can double-count activity or turn missing data into a false zero.

Usage is not value

A session count answers "was this used?" It does not answer "did this help?" A team can generate many sessions because an agent is useful, because it keeps failing, or because its workflow fragments one job into many starts.

Pair adoption data with delivery evidence: accepted suggestions, defects found before merge, escaped defects, review latency, rework, and the percentage of agent-authored changes that pass without human correction. GitHub has been expanding its Copilot metrics around review cycles and adoption phases, but administrators still have to define the outcome that matters.

A simple rollout: control depth, then measure the result

The four-week experiment I would run

1. Classify repositories by consequence. Put small internal tools and low-risk libraries in a Lite cohort. Put authentication, payments, infrastructure, and shared APIs in Balanced.
2. Freeze the policy for a full reporting window. Avoid changing defaults every few days or the comparison becomes noise.
3. Track agent activity beside review outcomes. Use stable agent IDs, then join sessions and interactions to defects caught, review time, and rework.
4. Change one variable. If Balanced finds more actionable defects but adds unacceptable delay, narrow it to high-risk paths instead of declaring the whole setting good or bad.

This is the same discipline we recommended when GitHub paused the Kimi K3 Copilot rollout: stage the model, preserve a fallback, and treat production behavior as evidence. It also complements our guide to how coding agents change software work, because adoption only becomes meaningful when the job and acceptance criteria are explicit.

Update: GitHub adds an ROI model and labels it directional

Update, August 9, 2026: GitHub has added a "Potential return on investment" section to the Copilot impact dashboard. It compares developers in Passive and Phase 1 cohorts with agent-first developers in Phase 2 and Phase 3.

What the new Copilot ROI cards model

Card	Input	What it cannot prove
Cost per developer per month	Estimated from actual AI credit consumption.	Fully loaded operating cost or causal productivity.
Percent of payroll per month	Copilot cost divided by the salary band selected by the administrator.	Actual payroll; the salary value is a modeling input.
Pull requests per month	Average pull requests per developer in each adoption group.	Quality, difficulty, business value, or work that never became a pull request.

The dashboard puts spend and output side by side. That is useful scenario planning, not proof that deeper Copilot adoption caused more pull requests. Team composition, repository type, work mix, review policy, and who chooses to use agents can all affect both the adoption phase and the outcome.

GitHub also corrected an important counting problem. Impact-dashboard cohorts now include everyone active during the full 28-day window instead of only people active on the final day. Reports ending on a weekend or holiday could previously show sharply lower cohort counts. GitHub says the change affects the dashboard, not the usage metrics API or NDJSON exports.

Use the new section to form a hypothesis: "Agent-first teams cost this much and merge this many pull requests under this salary assumption." Then test the missing outcomes, including defects, review time, rework, incidents, developer satisfaction, and delivered customer value, before calling the difference ROI.

Read GitHub’s official Copilot ROI dashboard announcement.

Update: web Copilot exposes conversation history and token spend

Update, August 10, 2026: GitHub has expanded Copilot Chat on github.com with easier access to recent conversations, a minimized chat state that can be reopened while a response is in progress, and token-spend indicators. Clicking the token icon shows per-session and per-message quota. GitHub says the controls are generally available across all Copilot plans.

These are useful operating controls, but they measure different things. Conversation history helps a developer resume context. Minimizing the panel reduces interruption. Token indicators expose consumption. None of the three proves that an answer was correct, that the work was worth the cost, or that a long conversation should keep access to the same repository context.

How to interpret Copilot’s new web controls

Control	What it helps	What teams still need
Recent conversations	Resume earlier work without rebuilding the thread.	A retention and access policy for sensitive repository context.
Minimized chat	Browse GitHub while Copilot finishes a response.	Clear cancellation and permission boundaries for consequential actions.
Token-spend indicators	See per-session and per-message quota.	Accepted changes, review time, rework, defects, and delivered value beside spend.

The practical move is to treat token spend as an input, not an outcome. If a session consumes more quota, ask whether it also reduced review time or rework without increasing defects. Keep conversation retention and repository access in the governance review, because a resumable thread is also a resumable context boundary.

Read GitHub’s official Copilot web conversation-controls announcement.

The governance gap is now easier to see

GitHub Copilot review effort is visible on the review, but agent usage data is aggregated. That is a healthy boundary for trend reporting, yet it means the metrics are not a forensic log. Teams still need repository audit events, pull-request history, and their own evidence trail when a specific change matters.

Agent identity also needs governance. A stable ID is useful only if administrators maintain an approved-agent register, know what repositories each agent may reach, and remove integrations that no longer have an owner. Our review of Claude Code cross-session messaging reaches the same conclusion: transport and visibility do not create ownership.

September 3 update: Copilot can count as an approval

GitHub Copilot code review now includes an approval assessment in every overview comment. That assessment is advice and does not satisfy a merge requirement. A separate approval action can count toward required approvals only when an administrator enables it. The feature is in public preview and remains off by default.

Controls exist at enterprise, organization, and repository level. Repository administrators can limit when an approval counts toward merge requirements using file-path patterns. This is separate from allowing Copilot to submit an approving review. If a new commit arrives after Copilot approves, GitHub dismisses the approval just as it would dismiss a human review, and a fresh review is required.

Keep high-risk paths out of the first rollout. Start with generated files or low-consequence repositories, require tests and code-owner rules independently, and audit false approvals as closely as useful findings. "Copilot says ready" and "Copilot approval satisfies policy" are two different states.

Read GitHub’s official approval announcement.

September 6 clarification: approval and merge credit are separate controls

In repository Settings → Copilot → Code review, GitHub documents two controls: allowing Copilot to approve pull requests, and allowing those approvals to count toward merge requirements. Enabling the first does not mean the second has been enabled. The feature remains a public preview.

For path-scoped counting, every changed file must match at least one allowed glob. GitHub supports up to 15 patterns, one per line. A blank path field covers all files. See the current configuration documentation; organization and enterprise policy can also constrain repository choices.

For example, if the only allowed pattern is docs/**, a pull request changing docs/start.md alone fits that scope. A pull request also changing src/auth.ts does not meet the all-files condition. This is an illustration of the documented rule, not a live configuration test.

Before rollout, test an in-scope change and a mixed-path change in a disposable repository. Confirm the effective policy rather than judging by the presence of an approval badge. Keep required tests and the human ownership of consequential changes explicit.

September 18 update: the impact dashboard now separates feature engagement

GitHub has added feature-level engagement to the Copilot impact dashboard. Administrators can now see 28-day engagement for code completion, agent edit, passive code review, active code review, the cloud coding agent, Copilot CLI and the Copilot app.

How to read Copilot feature engagement

Dashboard rule	What it means	What it does not mean
Two active days in 28	A user counts as engaged after activity on at least two days in the window.	Daily use, sustained proficiency or completed work.
Multiple feature counts	The same user can appear in more than one feature category.	Feature counts can be added to estimate unique users.
Aggregate reporting	Leaders can compare adoption patterns without a user-level leaderboard.	A forensic record of one developer’s actions or output quality.
Null or absent data	A metric can be unavailable when GitHub cannot calculate it.	Zero engagement.

The two-day threshold makes the cards an adoption signal, not a productivity score. A user can engage with a feature because it works well, because a task requires repeated correction or because policy makes the feature available by default. Compare the dashboard with accepted changes, review latency, rework, defects and delivered outcomes before attributing value.

Do not sum the feature cards to estimate total users. One developer can use completion, agent edit and CLI in the same window. Treat unavailable data as unknown rather than zero, and confirm that the organization has the permissions and usage-policy configuration GitHub requires for the report.

Read GitHub’s official feature-engagement announcement.

September 18 update: CLI customization counts have new double-counting traps

GitHub has added agentic CLI customization fields to the Copilot usage metrics API. The new totals cover skills, custom agents, MCP servers, slash commands and plugins. They help administrators see which extension surfaces are being used, but they are adoption counters rather than task-quality or return-on-investment measures.

How to interpret the new Copilot CLI arrays

Field group	What it records	Counting warning
totals_by_skill	Usage grouped by skill	A plugin interaction can also appear as a skill interaction.
totals_by_custom_agent	Usage grouped by custom agent	Use does not establish that the agent completed a task successfully.
totals_by_mcp	Connection and reconnection attempts by MCP server	interaction_count includes failed attempts and is not a tool-call count.
totals_by_slash_cmd	Usage grouped by slash command	Repeated invocation can reflect correction or confusion.
totals_by_plugin	Usage grouped by plugin	Do not add plugin totals to skill totals.

The MCP definition is especially easy to misread. GitHub says interaction_count records connection or reconnection attempts, including failures. A high value may indicate active use, an unstable server or repeated authentication problems. Pair it with connection success, tool execution, task completion and error metrics before calling the integration adopted.

Plugin and skill counts overlap because plugin interactions are also skill interactions. Adding the two totals inflates activity. Keep each array as a separate lens, report distinct users where GitHub supplies that measure and document the time window used for every comparison.

The same rule applies to the new copilot_feature_engagement field and its totals_by_feature breakdown: a user counts after activity on at least two days in a rolling 28-day period, and one user may engage with several features. The dashboard can show where attention is moving, but accepted changes, defects, rework and delivered outcomes still determine whether the activity was valuable.

Read GitHub’s official CLI customization metrics announcement and its feature-engagement announcement.

My verdict: spend reasoning where failure is expensive

The useful move is not to switch every repository to Balanced or crown the agent with the most sessions. Use review effort as a risk control. Use agent metrics as an adoption signal. Then attach both to outcomes a team would care about even if AI disappeared tomorrow.

Start with the repositories where failure is expensive. Give them the deeper review pass. Measure whether it finds issues people act on. Watch which agents earn repeat use. Retire the ones that create motion without better software.

Read the source record

• Read GitHub’s review effort GA announcement.
• Read the third-party agent metrics announcement.
• Check GitHub’s Copilot code review documentation, including its validation warning.
• Compare the policy with our overnight coding-agent handoff checklist.

Which repository deserves your deepest automated review, and what result would prove the extra effort was worth it?

Checked August 8, 2026. Product behavior and field definitions come from GitHub’s official changelog and documentation. GitHub does not claim that session or interaction counts measure code quality; the rollout framework above is Musthave.ai’s recommendation.

September 11 update: Copilot can auto-resolve addressed comments

GitHub Copilot code review can now mark a review comment resolved when a rereview determines that a new commit addressed it. GitHub also adds a generated commit message when a developer applies a suggested change from Copilot.

Auto-resolved is a workflow state, not proof that the change is correct. The later review decided the specific comment was addressed. Tests, code owners, branch rules and human approval still determine whether the pull request should merge.

GitHub reports more addressed findings at lower cost

GitHub-reported experiment result	Change	Interpretation limit
High-severity findings addressed	47% higher	Vendor experiment, not an independent reproduction
Medium-severity findings addressed	31% higher	Depends on finding and workflow mix
Low-severity findings addressed	11% higher	Does not measure downstream defects
Cost	8% lower	Experiment configuration and pricing matter

GitHub says Copilot code review can run builds, tests, scripts, tools and APIs behind an agent firewall. It also says Lite now uses an ensemble of agents. These changes expand what an automated review may execute, so repository owners should audit network, secret and tool permissions beside finding quality.

Measure reopened comments before trusting auto-resolution

A useful rollout measures four outcomes: comments auto-resolved, comments reopened by a person, related tests that later fail and defects that escape after merge. A high resolution rate with a high reopen rate signals workflow motion, not better review.

Start with repositories that have deterministic tests and clear ownership. Sample resolved high-severity comments every week, and preserve the original comment, fixing commit, rereview result and final human decision in the audit record.

VS Code Agents now have their own usage window

GitHub’s Copilot usage metrics now include VS Code Agents. The metrics are separate from editor Agent Mode, so administrators should not merge the two labels into one series.

VS Code Agents field	What it measures	What it does not prove
Daily active users	People who used VS Code Agents that day	Completed or accepted work
session_count	Agent sessions in the window	Productivity or task difficulty
total_user_messages	User messages sent in sessions	Quality, efficiency or business value
Per-user used flag	Whether a person used the feature	How much value the person received

Join review state to outcomes, not activity

Create one report with review effort, findings, auto-resolutions, reopened comments, test outcomes and merge decisions. Create a separate adoption report for VS Code Agents. Join them only at an appropriate aggregate level and never treat messages or sessions as completed work.

For another organization-level rollout control, see our GitHub AI Scan pull-request APIs guide. The Copilot agentic autofix analysis covers the boundary between a generated fix and a verified remediation.

Read the September 11 sources

• GitHub auto-resolution and code-review analysis update
• GitHub VS Code Agents usage-metrics update

Update checked September 12, 2026. Product behavior and experiment figures are attributed to GitHub. Measurement guidance is MustHave.ai analysis.