Desktop app: enterprise managed settings ignored for telemetry, and exported spans omit GitHub repo/org/branch attributes

Describe the bug

The GitHub Copilot desktop app (Windows) does not apply enterprise managed settings for telemetry. The same managed-settings.json policy that successfully configures OTel export for Copilot CLI on the same machine, for the same user, produces no export at all from the desktop app.

The app ships instrumented and is capable of exporting — it emits the same span shapes as the CLI (invoke_agent, chat <model>, execute_tool <name>), because it runs the CLI runtime internally. It just never picks up the policy that says where to send them.

The only configuration route that works is user-scope environment variables, which has two consequences:

1. Where the collector requires authentication, the credential has to be written into the user's environment — a static token in HKCU:\Environment, readable by any process running as that user and persisted across reboots. Managed settings avoid this by fetching the credential at runtime and never storing it in usable form; the environment-variable route gives that property up. This applies only to authenticated collectors, but that is a normal enterprise setup and presumably why telemetry.headers is a supported managed setting in the first place.
2. OTEL_EXPORTER_OTLP_ENDPOINT is not app-scoped, so setting it for the desktop app also exposes it to the CLI on the same machine. This applies regardless of collector authentication.

Beyond the credential handling, the general problem is that enterprise telemetry policy does not reach this surface at all. Any managed telemetry setting — endpoint, protocol, captureContent, lockCaptureContent — is silently ignored. lockCaptureContent is worth calling out: a policy whose purpose is to prevent prompt content being captured simply does not apply here.

Separately, when export is forced on via environment variables, the resulting spans omit the GitHub context attributes that the CLI and VS Code emit, so desktop usage cannot be attributed to a repository or organisation. Details below.

Affected version

• GitHub Copilot desktop app 1.1.16 (Windows)
• GitHub Copilot CLI 1.0.83 (same machine, same user — policy applies correctly here)

Steps to reproduce the behavior

1. Configure enterprise managed settings with a working telemetry block:

   {
     "telemetry": {
       "enabled": true,
       "endpoint": "https://<collector-host>",
       "protocol": "http/protobuf",
       "headers": { "Authorization": "Bearer <token>" },
       "captureContent": false,
       "lockCaptureContent": true
     }
   }
   

2. Run Copilot CLI, send a prompt. ✅ Spans arrive. The policy is valid and reachable.

3. Ensure no OTEL_* / COPILOT_OTEL_* environment variables are set for the user.

4. Fully quit the desktop app from the system tray (closing the window is not sufficient), relaunch, send a message.

5. ❌ No OTLP requests are made. Nothing is exported.

6. Now set the following as user-scope environment variables, quit from the tray again, relaunch, send a message:

   COPILOT_OTEL_ENABLED=true
   OTEL_EXPORTER_OTLP_ENDPOINT=https://<collector-host>
   OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
   OTEL_EXPORTER_OTLP_HEADERS=Authorization=Bearer <token>
   

7. ✅ The app exports OTLP traces, using the same endpoint and token the managed policy already specified.

   The delta between step 5 and step 7 is only where the configuration came from.

8. With the app open on a GitHub-hosted repo on a named branch, inspect the invoke_agent spans that now arrive.

9. ❌ None of github.copilot.git.repository, github.copilot.git.branch, github.copilot.git.commit_sha or github.copilot.github.org are present.

Exported spans omit GitHub repo/org/branch attributes

Once export is enabled, the spans are the right shape — same names (invoke_agent, chat <model>, execute_tool <name>), same gen_ai.* and token / nano_aiu attributes — but they omit the GitHub context attributes that CLI and VS Code Chat emit when in a git repo:

• github.copilot.git.repository
• github.copilot.git.branch
• github.copilot.git.commit_sha
• github.copilot.github.org

Desktop usage is therefore visible in aggregate but cannot be attributed to a repository or organisation, which is what most enterprise reporting on this data needs.

Note also that environment variables cannot substitute here even in principle: a single desktop instance holds several projects open at once and switches between them, so no process-scoped value could describe the repository for a given session.

Expected behavior

Two things, independently useful:

1. The desktop app should honour enterprise managed settings for telemetry, as the CLI does, so that a single enterprise policy governs every Copilot surface.
2. Desktop-app spans should carry the same GitHub context attributes as the CLI and VS Code, resolved from the project and workspace the session already belongs to.

Additional context

The shared cache is not a viable workaround. The desktop app shares %LOCALAPPDATA%\copilot with the CLI, so the CLI's fetched policy is on disk and readable. But the cached copy stores the header redacted at rest, so it cannot be replayed:

%LOCALAPPDATA%\copilot\managed-settings\<account-hash>.json

// Disposable cache for enterprise managed settings, safe to delete. Managed automatically.
{"schemaVersion":1,"retrievedAtMs":...,"account":"...","response":{"telemetry":{
  "enabled":true,
  "endpoint":"https://<collector-host>",
  "protocol":"http/protobuf",
  "headers":{"Authorization":"******"},   <-- redacted; live value only ever arrives via a fetch
  "captureContent":false,"lockCaptureContent":true}}}

The endpoint survives the round trip but the credential does not, so a host that does not fetch cannot authenticate regardless of what the CLI has cached.

Likely cause of the managed-settings half (inference, not confirmed from source). Self-fetching managed settings appears to be opt-in per session: the SDK exposes an enableManagedSettings flag, documented as making the runtime self-fetch enterprise managed settings at session bootstrap, and the host application has to ask for it. The CLI does; the desktop app appears not to. The missing repo attributes look like a separate gap in the same area — the host not passing its project/workspace context into the runtime's OTel tracker. Happy to be corrected on either mechanism; the observed behaviour in steps 1–9 stands regardless.

No user-facing workaround for the managed-settings half. enableManagedSettings is an SDK API field set in the app's own code. There is no setting, flag or environment variable that flips it from outside, which is what leaves environment variables as the only route.

Verification note. github.exe never connects to the collector itself — it spawns copilot.exe child processes that do the exporting, so looking for github.exe in a connection list suggests a failure that has not happened. Check process parentage instead:

$ip = (Resolve-DnsName '<collector-host>').IPAddress
Get-NetTCPConnection | Where-Object { $_.RemoteAddress -in $ip } |
  Select-Object -ExpandProperty OwningProcess -Unique | ForEach-Object {
    $p   = Get-CimInstance Win32_Process -Filter "ProcessId=$_"
    $par = Get-CimInstance Win32_Process -Filter "ProcessId=$($p.ParentProcessId)"
    "{0} <- parent {1}" -f $p.Name, $par.Name }

copilot.exe <- parent github.exe is the desktop app exporting; copilot.exe <- parent powershell.exe is the ordinary CLI. The app also reads its environment once at process start, and Explorer caches the environment it hands to the apps it launches — so a tray quit and relaunch is required, and occasionally a sign-out/sign-in.

Environment. Windows 11, x86_64. Desktop app launched from the Start menu / tray, opened on a GitHub-hosted repository on a named branch using a Local (branch) workspace.

Possibly related:

• #4669 — managed telemetry.headers prevented CLI export (fixed). That is the CLI mishandling a policy it did fetch; this is a host never fetching one.
• #3477 — enterprise OTel auth options.
• #3909 — server-managed settings for the local CLI.
• #4556 — server-managed extraKnownMarketplaces fetched but never applied in the desktop app, which may share a root cause in how the desktop host consumes managed settings.

从桌面主机的引导启动开始，跟踪 SDK 的 enableManagedSettings 路径、copilot.exe 进程，以及接收项目或工作区上下文的 OTel tracker。完成的标准是桌面应用应用了托管的遥测设置，并且其 invoke_agent spans 包含所列出的 GitHub repository、branch、commit 和 organisation 属性。