GitHub has published an October 6, 2026 fix for a Copilot usage-metrics attribution issue affecting agent sessions in some IDEs. The practical takeaway for QA leaders is simple: do not interpret a recent drop in agent activity or agent-authored lines of code as a real behavior change until the affected developer clients are updated and the reporting window is re-baselined.

What GitHub changed

GitHub says several IDEs moved Copilot agent sessions to the Copilot SDK without identifying the originating IDE. As a result, much of that activity was omitted from usage reports, while some activity was attributed to Copilot CLI. The issue applies only to IDE versions using that SDK path; earlier versions remain counted.

  • VS Code: version 1.139.0 or later is available now.
  • Visual Studio: version 18.12 is expected in October 2026.
  • JetBrains: the next plugin release is expected by late October 2026.
  • Eclipse and Xcode: their next plugin releases are expected by November 2026.

GitHub also notes that missing activity cannot be backfilled. That means a team should expect gradual recovery in agent interactions and agent-edit line counts as developers update—not a repaired historical trendline.

Why this matters for QA engineers

QA and automation teams increasingly use Copilot dashboards and exports to measure whether agent-assisted test creation, test maintenance, and pull-request review are actually being adopted. An attribution gap can make a healthy pilot look stalled, or make CLI activity look larger than it really is. It can also distort before-and-after comparisons for an enablement program.

This is not a billing correction: GitHub says charges were unaffected. It is a data-quality correction for detailed usage reporting. Active-user totals can still draw on server-side telemetry, but richer metrics such as feature breakdowns and lines of code depend on client telemetry.

A practical QA reporting checklist

  • Inventory IDE versions: use per-user totals_by_ide fields such as last_known_ide_version and last_known_plugin_version to identify affected clients.
  • Set a reporting annotation: mark the period before the fixed client rollout as potentially incomplete for agent interactions, agent_edit lines added, and deleted-line measures.
  • Separate real CLI work: avoid treating historic Copilot CLI growth as conclusive while GitHub says SDK-based IDE activity may have been attributed there.
  • Verify the telemetry path: keep Copilot telemetry enabled and make sure proxies or firewalls allow the telemetry endpoint.
  • Re-baseline, do not backfill: establish a clean baseline after the update reaches the relevant IDE fleet, then compare future 28-day windows on the same client-version mix.

What to validate after rollout

Treat this like any observability change. Select a small group of QA engineers who use agent mode in the affected IDE, record their client and extension versions, then compare their session activity before and after updating. Confirm that their usage appears in the expected IDE breakdown and that a known agent edit produces the expected detailed telemetry. Keep this validation separate from claims about test-quality improvement: usage data can show adoption and engagement, but it does not prove that generated tests are correct or that releases are safer.

Sources

Bottom line: update the affected IDE clients, label the affected historical window, and use a fresh baseline for GitHub Copilot agent metrics. That gives QA leaders a more defensible view of agent adoption before they change training, tooling, or quality-gate decisions.