Skip to content
Betav0.62.0
All articles

Coding-agent telemetry now shows who acted and what was stopped

Copilot can now attribute activity to a user without capturing content, and Claude Code logs stopped tool calls. What to collect and how to read it.

By The SpanDock team

5 min read

A diagram of agent telemetry answering two questions, who acted and what was stopped, with identity attributes on one side and permission, hook and sandbox outcomes on the other, and content capture kept separate

Two questions come up in almost every review of AI coding agents: who ran this, and what did the controls stop? Until recently, answering either from OpenTelemetry often meant switching on prompt and tool-content capture, which brings source code and commands into your telemetry. In October both GitHub and Anthropic shipped changes that answer these questions more directly. Copilot can now attach a user and machine to its telemetry without capturing content, and Claude Code has added an event for each tool call that a control stopped, prompted or sent back. This article explains what each change records, the caveats in reading it, and a sensible default for collection.

Context

Our earlier article on content capture as a privacy decision argued that prompts and tool output should not be collected by default. The difficulty was that attribution and policy outcomes were often bundled with content, or not emitted at all. Both vendors' changes separate them further.

What GitHub changed

On 12 October 2026 GitHub announced that enterprise administrators can use the telemetry key in managed settings "to attribute GitHub Copilot activity to a user without collecting their prompts, responses, or tool content". Setting telemetry.capture.identity adds three attributes:

  • user.name, the authenticated Copilot account name, currently the GitHub login;
  • process.user.name, the local operating-system account;
  • host.name, the machine name.

Identity is off by default and separate from the existing pseudonymous identifier. Five content classes can be enabled independently, and all are also off by default: prompts, responses, tool arguments, tool output and policy detail. The OpenTelemetry concepts page adds a useful detail: with policy detail disabled, "Bounded policy posture and outcomes remain available". In other words, you can see that a sandbox or policy blocked something without collecting the raw paths involved.

The managed settings reference sets out the precedence rules. Managed values override local settings, SDK configuration and environment variables. The older captureContent switch turns the five content classes on or off together, unless a class is set explicitly, but never enables identity, and lockCaptureContent stops local settings from enabling content classes that the managed configuration leaves unset. Two scope limits matter: fine-grained controls work in Copilot CLI, the GitHub Copilot app and VS Code sessions using Agent Host, while VS Code's local agent harness supports identity and the legacy all-or-nothing switch only. Also note that the tool arguments class includes denied resources, so the detail of what was refused sits with content, not with outcomes.

What Anthropic changed

Claude Code's v2.1.307 release, published late on 21 October 2026, added a claude_code.safety_event OpenTelemetry event "for each tool call a permission rule, auto mode, a safety check, a hook or the sandbox stopped, prompted or sent back". At the time of writing, the monitoring documentation does not yet describe the event's attributes, so it is worth waiting for that before building dashboards on specific fields.

The existing tool_decision event already carries much of this. It records whether a call was accepted or rejected and where the decision came from: configuration, a hook, or the user. Since v2.1.301 it also records the auto mode classifier's verdict and the active permission mode. The documentation includes caveats that matter for anyone counting denials:

  • A classifier_verdict of "unavailable" means the request to the classifier failed, for example on a rate limit or timeout, and the call was denied. "no_verdict" means the check gave no usable answer; the documentation says this denial "doesn't mean the classifier found the call unsafe".
  • A classifier check that fails partway through can also end as "block", so a partial outage can look like a rise in blocks.
  • For user-configured MCP servers, the event's tool name is always "mcp_tool"; the server and tool names appear only when OTEL_LOG_TOOL_DETAILS is enabled, which also brings in commands and arguments.

Identity also works differently. Claude Code's standard attributes include the user's email address whenever it is available, the organisation identifier when available, and an account identifier that can be dropped from metrics but is listed among the standard attributes of events. Copilot's model is the reverse: pseudonymous by default, identity by opt-in.

What it means for engineering and security leaders

  • Attribution without content is now a realistic default. For most audit and support questions, knowing which person and machine ran a session, and which controls fired, is enough. Content can stay off until an investigation needs it.
  • Identity is still personal data. A GitHub login, an OS account name and a host name identify people. Turning identity on deserves the same notice and retention decisions as any other employee monitoring, and in some organisations a works council conversation.
  • Denials are two signals in one. A rising number of stopped calls may mean an attack, an over-strict rule that is slowing people down, or an outage in a classifier. Read the source and verdict before drawing conclusions.
  • Managed settings decide what is collected. On Copilot, the managed configuration wins over local and environment settings, so the collection policy can be enforced centrally rather than trusted to each developer's machine.

Practical takeaways

  1. On Copilot, decide whether to enable capture.identity and leave the five content classes off unless there is a documented need. Consider lockCaptureContent.
  2. Check which Copilot surfaces your developers use; VS Code's local agent harness does not apply the fine-grained content classes.
  3. On Claude Code, review whether you need user.email on every event, and record that decision alongside your telemetry policy.
  4. Build a simple view of rejected tool_decision events by source and classifier verdict, and separate "unavailable" and "no_verdict" from real blocks.
  5. Plan to add claude_code.safety_event once its attributes are documented, and test it on v2.1.307 or later first.
  6. Agree who can see identified telemetry and how long it is kept.

SpanDock follows the same principle for its own collection. Per the privacy page, when it configures a tool under Integrations it sets the tool up to report usage, timing, tokens and cost rather than what was typed or read. On the Enterprise plan, guardrails record each match as an event with the rule, the action and the outcome, never the prompt, arguments or result.

Sources

  1. GitHub Changelog: Client telemetry user attribution and configurable capture (12 October 2026)
  2. GitHub Docs: OpenTelemetry for agent monitoring
  3. GitHub Docs: Enterprise managed settings reference
  4. Claude Code release v2.1.307 (21 October 2026)
  5. Claude Code documentation: Monitoring
Cookie categories

Details: Cookie Policy.