GitHub refined Copilot's OpenTelemetry settings on October 12. One-line summary:

All-or-nothing → per-item controls

Identity and five content classes can now be enabled independently. If you operate Copilot in a company, this is a change worth knowing.

The six capture classes in one table

From the official docs:

Identity
  → Copilot account + OS account + machine name
  → shows "who" without conversation content

Prompts
  → user, system, and developer prompts plus model input

Responses
  → assistant responses plus supported reasoning

Tool arguments
  → raw commands and args, tool schemas, MCP/plugin/hook IDs

Tool output
  → tool results and execution error detail

Policy detail
  → unbounded policy info such as raw sandbox paths
  → bounded posture and outcomes stay visible when off

The key fact is the default: everything sensitive is off. Without opt-in, prompts, responses, and tool arguments never leave. Metadata such as model names, token counts, and durations is the starting point.

Coverage differs:

Copilot CLI · Copilot app · VS Code Agent Host
  → all six classes independently controllable

VS Code local harness
  → identity plus legacy all-or-nothing content only
  → five-class split not yet applied

Why it matters: observability vs exposure

Without agent traces you cannot operate: who ran which session, with which model, how many tokens, how many tool failures. The three signals:

traces  → session flow (model calls + tool use linked)
metrics → patterns over time (tokens, tool success)
events  → single actions (accept / reject)

Collecting everything is convenient for debugging and alarming for security, because prompts and tool results carry source code, file contents, commands, and workspace paths. Granularity lets you pick the middle:

Stage 1: identity only
  → adoption without content

Stage 2: + tool error output
  → failure analysis, minimal exposure

Stage 3: prompts/responses for one team, briefly
  → time-boxed quality investigation, then off

Practical setup: enforce with managed settings

Do not trust local settings in an enterprise; enforce with managed configuration. Conceptually:

{
  "telemetry": {
    "enabled": true,
    "endpoint": "https://otel-collector.example.internal",
    "captureIdentity": true,
    "capturePrompts": false,
    "captureResponses": false,
    "captureToolArguments": false,
    "captureToolResults": true,
    "capturePolicyDetail": false
  }
}

In words:

- export on, but only to our collector
- identify who, collect no conversation content
- collect tool results for failure analysis
- skip raw policy paths

Local VS Code keys worth knowing:

github.copilot.chat.otel.enabled         → on (default false)
github.copilot.chat.otel.captureContent  → all content (default false)
github.copilot.chat.otel.captureIdentity → identity (default false)
COPILOT_OTEL_ENABLED / OTEL_EXPORTER_OTLP_ENDPOINT → env-var style

Data goes to an OTLP backend, directly or via a Collector, following GenAI semantic conventions (gen_ai.*), so Jaeger, Grafana, Datadog, and friends attach directly.

CodeBridge mini lab: a 30-minute collection review

[ ] Is the destination under our control (endpoint + auth)?
[ ] Only needed classes on (start with identity)?
[ ] Storage location, retention, and access documented?
[ ] Sensitive repos excluded or time-boxed?
[ ] Accept-rate and tool dashboards built from metadata alone?

The commonly missed item is storage: who can read raw prompts, and for how long. If that is undecided, keep the content classes off.

Conclusion: observe broadly, collect narrowly

Metadata broadly, content only when needed.

Observability for AI coding tools is not about collecting more logs; it is about deciding what not to collect. Start from off-by-default and enable only what the investigation needs.

Further reading

References

Go deeper with a course

Apply Agent and Plan modes to a real project and learn where observability actually pays off.