Copilot agent activity mysteriously falling? GitHub confirms an IDE attribution bug — missing data can't be backfilled

Bottom line first: your agent metrics may be quietly "disappearing" — but your team isn't slacking

If you're in charge of AI coding-tool adoption at your company, or you hand a Copilot usage report to management every month, you may have seen this scene in recent weeks: agent activity and agent lines of code in the report keep sliding downhill, the curve looking as if the whole team suddenly abandoned agent mode — while Copilot's overall usage curve keeps climbing steadily, with license activations and active users all intact.

Two curves moving in opposite directions. Management's first instinct is usually to assign blame: did the rollout fail? Did everyone go back to writing code by hand? GitHub gave the official answer in its October 6, 2026 Changelog — don't rush into a post-mortem; this isn't a people problem, it's a reporting problem. Several IDEs recently moved Copilot agent sessions to the Copilot SDK, and those sessions no longer identify which IDE they came from, so usage metrics lost the ability to attribute them: most of that activity fell straight out of the reports, and some of it was misrecorded under Copilot CLI.

In other words, your team may have been using agent mode intensively all along — the credit just went missing from the reports. And the painful part is that GitHub said the ugly truth up front: this lost data will never come back.

The strange fork in the reports: agent metrics down, overall usage up

GitHub describes the symptom precisely in the original post: "If your Copilot usage metrics have shown agent activity or agent lines of code falling while Copilot usage kept growing, we've found the cause." This isn't one company's isolated case — it's systemic. Any developer whose IDE version runs agent mode on the Copilot SDK has their agent interactions and agent lines of code (e.g., loc_added_sum and loc_deleted_sum for agent_edit events) persistently undercounted. Developers on older IDE versions are unaffected and still counted normally.

Note this "old versions fine, new versions missing" detail — it explains why report discrepancies within the same company can be huge across teams: the teams that upgrade enthusiastically show the ugliest numbers, while the teams that never bothered to upgrade look perfectly healthy. That's the most misleading combination possible — a manager seeing Team A's agent metrics halved while Team B's are untouched will easily conclude "Team A's rollout failed," when the truth is the exact opposite: Team A "disappeared" precisely because they upgraded to the new IDE version.

So the first judgment stands here: as of October 2026, any team-to-team comparison or performance review based on agent activity and agent lines of code is unreliable. Evaluating teams with this report is like measuring height with a ruler that's missing markings.

Root cause: a group of IDEs moved house, and the "ID card" got lost halfway

To understand what happened, you need to know how Copilot usage metrics get their data. GitHub lays out the mechanism candidly in the post: the most granular usage metrics — feature, language, model, and lines-of-code breakdowns — all come from client-side telemetry that each IDE sends. GitHub also records server-side data when Copilot handles a request, which reliably shows who was active but can't see what happens inside the editor.

The migration itself was fine; the attribution field is what got lost

Several IDEs moving agent sessions to the Copilot SDK was, technically, a reasonable and even commendable architectural consolidation: running agent mode on a unified SDK means more consistent behavior and lower maintenance cost. The collateral damage was in the migration — sessions going through the SDK no longer carry the "which IDE am I from" identifier. The server receives the request and can confirm "this is an active user," but when the attribution system asks "whose agent activity is this," it gets a blank.

GitHub's handling is honest but brutal: unattributable activity was mostly excluded from reports outright; another portion, traveling the same SDK channel, was mistaken for Copilot CLI activity. That created a second set of cooked books.

Two sets of cooked books: the missing, and the misattributed

The first set is undercounting: agent interactions and agent lines of code on affected IDE versions stay undercounted, covering enterprise, organization, and user-level reports, in both 1-day and 28-day report windows. Whether you pull daily or monthly reports, the hole is there.

The second set is misattribution: Copilot CLI metrics may be inflated, because some activity from other SDK-based clients was counted as Copilot CLI activity. If you've seen CLI usage inexplicably surge in recent months, don't rush to hand the CLI team a bonus — some of that may be "water" from VS Code and JetBrains users. GitHub states plainly that real Copilot CLI users don't need to update anything; the misattribution will clear up on its own as IDE clients get updated.

But "clearing up on its own" only fixes the future, not the past. Which brings us to the single most important sentence of this whole story.

The harshest sentence: the lost data is gone for good

We can't backfill missing data.

That's GitHub's original wording, verbatim. The reason is equally blunt: activity from affected IDE versions never identified its source IDE, so there is no way to attribute it after the fact. Agent line counts from the missing period stay permanently undercounted, and the historically inflated CLI numbers can't be corrected either — because that activity is now inseparable from genuine CLI usage.

Translated into management language: the Copilot agent usage data for the second half of 2026 has a permanent, unfixable gap. It won't "bounce back" when the fixes finish rolling out in November; the reports will only show a gradual recovery as developers move to fixed versions — the curve climbing slowly, not jumping back to normal in one leap. GitHub emphasized this deliberately, fearing exactly the misread: someone seeing the curve fail to snap back at the end of November and assuming a new problem appeared.

The one piece of good news is billing: "Billing isn't affected." This incident only changed how agent activity was attributed in usage metrics, not what anyone was charged. Not a cent more spent than there should have been — this is purely a statistics-caliber problem.

Team manager's action checklist: four steps, in order

The value of this story starts here. The checklist below is for anyone running a Copilot rollout, managing IDE versions, or delivering usage reports. Do them in order; don't skip steps.

Step 1: Diagnose first — how deep does your exposure go?

Don't estimate by gut feeling; pull the per-user reports directly. GitHub hands you the tool: in the totals_by_ide field, every user carries last_known_ide_version and last_known_plugin_version. Sweep those two fields across the company and you instantly get three lists: developers already on fixed versions (VS Code 1.139.0 and later), developers still on affected versions, and those not on any known IDE at all.

The list serves two purposes: it quantifies your data gap — the higher the share of affected users, the less trustworthy your recent agent metrics are; and it becomes the target list for the upgrade rollout in step 2. Note GitHub's explicit advice: "If you manage IDE versions centrally," plan the rollout to move developers directly to the fixed versions. Don't do it gradually — go straight there in one move.

Step 2: Match each IDE to its timeline and watch the upgrades

The fixed versions and timelines from the official post are below, with the full rollout expected to complete by the end of November 2026:

• Visual Studio Code: version 1.139.0 and later, available now. The only environment you can act on today, and VS Code users are usually the largest share — plug this biggest hole first.
• Visual Studio: version 18.12, expected in October 2026. Not released yet; stay tuned and push it the moment it ships.
• JetBrains IDEs: next plugin release, expected by late October 2026. JetBrains users tend to be heavy agent-mode users — this gap may be bigger than you think.
• Eclipse: next plugin release, expected by November 2026.
• Xcode: next plugin release, expected by November 2026.

Practical advice: enforce minimum versions through your device management tooling (MDM / group policy / internal upgrade channels) instead of sending a "please upgrade" email and waiting for volunteers. GitHub's line — "Keep IDEs and Copilot extensions current. Use your device management tooling to enforce minimum versions where you can" — isn't politeness. This incident proves that fragmented client versions are themselves a metrics risk.

Step 3: Translate the "data gap" into language management understands

This is the easiest step to overlook and the most critical one. Management doesn't care about SDKs and telemetry; they care about: "Are the agent adoption numbers you reported even accurate?" "Is the Q4 AI effectiveness review still happening?"

The suggested framing is a three-part statement: first, acknowledge the gap — agent activity and agent lines of code over recent months were systematically underestimated; this is not a team execution problem but a statistics-caliber incident confirmed by GitHub itself. Second, define the boundary — the gap only affects agent-dimension breakdowns; overall usage and active user counts are unaffected, and billing is untouched. Third, give the timeline — as fixed IDE versions finish rolling out through the end of November, data will gradually return to normal, but the historical gap is permanent; Q3–Q4 agent metrics must carry a caveat in any year-over-year or quarter-over-quarter comparison and cannot be compared directly.

One more reminder: if your company wrote Copilot agent adoption into OKRs or an effectiveness dashboard, now is the best time to request a "metrics-caliber exemption." Walking in with GitHub's official Changelog beats any verbal explanation — this is an upstream incident, not your fault, but it is your responsibility to let the organization know the ruler is bent.

Step 4: Break three old habits of reading Copilot reports

This incident really exposed a set of long-standing bad habits, which GitHub all but calls out by name at the end of the post:

1. Stop assuming "report numbers = reality." When reports disagree with other Copilot data, GitHub says the gap is usually on the client side: telemetry turned off, a proxy or firewall blocking the Copilot telemetry endpoint, an outdated IDE or extension not sending the events metrics rely on, a client changing how it sends telemetry (this incident), or a third-party editor that doesn't send Copilot telemetry at all. When you see an anomalous curve, check the clients before questioning the team.
2. Manage the telemetry channel as infrastructure. Keep IDE telemetry enabled and allow the Copilot telemetry endpoint through proxies and firewalls — GitHub singles out both. For enterprises with strict security policies, this usually means a formal allowlist process with the security team; don't let "deny by default" silently eat your data.
3. Make IDE version inspection routine. The last_known_ide_version / last_known_plugin_version fields in totals_by_ide shouldn't only be looked at during incidents. Make it a monthly inspection item and raise an alert whenever version distribution lags badly — in this incident, "old versions happened to report fine" was a coincidence; next time client telemetry breaks, the lagging versions could be the hardest hit.

Opinion: this isn't just an incident — it's the coming-of-age of Copilot's metrics system

Treating this as merely "GitHub shipped a bug, upgrade and move on" wastes its real value. What's worth savoring is the direction GitHub reveals in the second half of the post: they are systematically reducing how much reports depend on client telemetry — usage metrics now use server-side data to count active users that client telemetry misses and to identify the IDE for those users, and they keep expanding where server-side data can fill in.

That's a clear-eyed judgment: staking core metrics on the telemetry switches of tens of thousands of developer machines is inherently fragile. This time it was a lost IDE identifier field; next time it could be a plugin version failing to emit an event; the time after that, some security software killing the telemetry endpoint as if it were a tracker. Server-side data can cover "who was active," but details like lines of code and accepted suggestions — "what happened inside the editor" — can only come from the client. GitHub admits it outright: client-side gaps won't disappear entirely.

So the real lesson cuts both ways: for GitHub, key attribution fields deserve server-side cross-validation instead of blind trust in client self-reporting; for enterprises, IDE version management and telemetry channel management should be promoted from "IT chores" to part of "data asset governance." The version-inspection, telemetry-allowlisting, and metrics-caveat processes you build for Copilot today will be reused verbatim for the usage audit of every agent tool tomorrow — after all, the agent era has just begun, and the number of tools needing audits will only grow.

One honest closing note: the people hurt most by this incident weren't the ones who lost data — they were the teams nearly held accountable on the basis of wrong data. If anyone in your organization has already been called in over falling agent metrics, forward them this Changelog now. Sometimes an official announcement is the best exoneration notice there is.

Timeline at a glance

• Visual Studio Code 1.139.0 and later: fix available now, upgrade immediately
• Visual Studio 18.12: expected in October 2026
• JetBrains IDEs next plugin release: expected by late October 2026
• Eclipse next plugin release: expected in November 2026
• Xcode next plugin release: expected in November 2026
• All IDE fixes expected to finish rolling out by the end of November 2026; Copilot CLI users don't need to update; billing unaffected