GitHub says some Copilot IDE-agent activity has been missing from its usage metrics dashboard and API because clients failed to identify the IDE that generated it. Engineering leads seeing a drop in reported agent interactions or code edits should check for this reporting gap before concluding that developers are using Copilot less.

In its October 6 announcement, GitHub attributes the gap to IDE agent sessions that moved to the Copilot SDK. Most affected activity was omitted; some was incorrectly counted as Copilot CLI activity. GitHub says billing was unaffected by this attribution issue.

Client updates are intended to improve reporting of subsequent activity, with recovery happening gradually as developers update. GitHub says the missing history cannot be restored.

Which activity is missing or misattributed?

GitHub identifies undercounted agent interactions and agent-generated lines added or deleted, specifically loc_added_sum and loc_deleted_sum for agent_edit. The problem affects enterprise, organization and user reports across both 1-day and 28-day reporting windows.

The affected clients are IDE versions that use the SDK for agent mode, according to GitHub. Earlier versions still counted their activity. The announcement does not provide a complete list of affected starting versions or an incident start date.

Some activity from other SDK-based clients was classified as CLI use, potentially inflating that series. GitHub says CLI users do not need to update for this issue: correcting future attribution depends on updates to the clients sending misidentified activity. Historical misclassified events cannot be separated from genuine CLI use.

How active-user counts help interpret missing detail

The Copilot usage metrics documentation distinguishes server-side participation signals from richer client-side telemetry, the activity data sent by the IDE or extension.

Server-side signals can count users toward active-user totals, such as daily_active_users, even when client telemetry misses their activity. Feature breakdowns such as totals_by_feature and line-of-code details can remain empty until richer telemetry is available.

Active-user totals help show who participated, while detailed metrics describe their recorded editor actions. Incomplete detail leaves too much activity unaccounted for to determine how a team’s actual Copilot use changed. A rise in reported activity after client updates could reflect restored measurement. Compare the participation and detailed-activity series with that reporting change in mind.

Which client fixes are available?

GitHub’s announced remediation targets differ from the older minimum versions listed in its general metrics-support documentation. Use the issue-specific targets below to check for this attribution fix.

Release status was checked on October 8, 2026:

Client GitHub’s announced correction Status at the check
VS Code 1.139.0 and later GitHub lists the fix as available.
Visual Studio 18.12 Expected in October.
JetBrains IDEs Next Copilot plugin release Expected in late October.
Eclipse Next Copilot plugin release Expected in November.
Xcode Next Copilot plugin release Expected in November.

The official VS Code 1.139 release notes confirm release-series availability; the attribution-fix threshold is documented in GitHub’s announcement. The release notes do not explicitly identify that fix. Check release notes for the other clients as their expected corrections become available.

What to check before the next management report

  1. Label the affected series. Identify the report scope and window, then flag IDE-agent interactions, agent_edit line counts and potentially inflated CLI activity. Keep affected history marked as incomplete or misattributed. GitHub says the missing IDE identity prevents backfilling, so any adjustments to historical values would require evidence the reports cannot supply.
  2. Check client versions. Per-user totals_by_ide entries can include last_known_ide_version and last_known_plugin_version. These record the most recently detected versions and may differ from a developer’s current installation. Compare them with an authorized managed inventory, where available, and use the issue-specific remediation targets.
  3. Plan updates through the normal process. Use approved client rollout procedures and confirm release status for forthcoming fixes. Mixed client versions can mean uneven reporting recovery.
  4. Review existing telemetry and network settings. Disabled telemetry, blocked endpoints and outdated or unsupported clients can also leave details missing. Ask the responsible administrators to review configuration within approved privacy and security policies. Preserve existing tracking decisions and security controls throughout that review.
  5. Allow for normal reporting delay. GitHub documents dashboard and API freshness within two full UTC days after the activity day closes. The processing clock starts at that day’s close, regardless of when a client update was installed. Assess subsequent activity after this interval, comparing participation totals with feature and line-of-code detail while keeping historical gaps marked.