[Bug] OTel metrics: skills from non-official plugin marketplaces report skill.name="third-party" with no opt-out — teams lose analytics for their own skills

Adding an independent reproduction on 2.1.220, plus one finding I don't think is in the thread yet: the mask also holds on the cost-bearing event, with OTEL_LOG_TOOL_DETAILS=1 enabled. Enabling that flag is therefore not a workaround for cost/token attribution — only for call counting.

Setup

• Claude Code 2.1.220, macOS arm64
• Metrics: OTLP → VictoriaMetrics → Grafana
• Separate probe run with OTEL_LOGS_EXPORTER=console and OTEL_LOG_TOOL_DETAILS=1 to read the events directly

What the flag does fix (confirming #17046)

tool_result / tool_decision carry real names in tool_parameters:

body: "claude_code.tool_result"
  tool_name: "mcp_tool"
  tool_parameters: "{\"mcp_server_name\":\"<our-server>\",\"mcp_tool_name\":\"list_datasources\"}"

body: "claude_code.tool_result"
  tool_name: "Skill"
  tool_parameters: "{\"skill_name\":\"<our-plugin>:<our-skill>\"}"

plugin_loaded goes further and emits the verbatim plugin name and the marketplace identity:

body: "claude_code.plugin_loaded"
  "plugin.name": "<our-plugin>"
  "marketplace.name": "<our-marketplace>"
  "plugin.scope": "user-local"

What it does not fix

In the same session, with the flag on, api_request — the only event carrying cost_usd — is still masked:

body: "claude_code.api_request"
  model: "claude-opus-5"
  cost_usd: 0.0232505
  cache_read_tokens: 26406
  "skill.name": "third-party"
  "plugin.name": "third-party"

Across the whole probe the verbatim skill name appeared exactly once — in tool_parameters, where there is no cost — while the costed event said third-party.

So three signals disagree inside one process and one turn: plugin_loaded knows the plugin and its marketplace, tool_result knows the skill name, and api_request, emitted milliseconds later, reports third-party.

Impact

30-day window, ~136 distinct named skills visible:

• skill.name="third-party" — 39.8% of all skill-attributed cost
• mcp_server.name="custom" — 85.7% of all MCP-attributed cost

The MCP figure is the worse one: every self-hosted server collapses into a single series, so "which internal MCP server is costing us" has no answer at all.

One consequence worth spelling out: because the mask keys on the distribution channel rather than on the skill, the same skill lands in different buckets depending on how each developer installed it. We have skills present both in our own marketplace and as loose directories in ~/.claude/skills, and their usage splits between a verbatim series and the third-party bucket. That makes the named series unreliable too, not only the opaque one — a per-skill number silently undercounts by however many people installed it the supported way.

Workaround, and why it isn't enough

All events in a turn share prompt.id, so a log pipeline can join the verbatim name from tool_result onto cost_usd from api_request. Two problems: attribution is ambiguous when several skills or subagents fire in the same turn, and it requires standing up an OTLP logs receiver purely to recover an attribute the metrics pipeline already holds. Teams running only a metrics backend — ours included — cannot use it at all.

Ask

plugin_loaded already carries a verbatim plugin.name and marketplace.name, so the identity is demonstrably available in-process. The gap is purely on the metrics side.

What would help is a metrics-side control, separate from OTEL_LOG_TOOL_DETAILS. That variable governs the logs signal, and making it the switch for a metric label would force operators who run only a metrics backend to enable full tool-parameter logging — tool_input, including complete bash commands — just to recover a plugin name. That is a far larger exposure than the label being requested, and it is the wrong signal to reach for.

Either shape would solve it:

• a trusted-marketplace allowlist, as proposed in #70547, so an organisation can un-mask marketplaces it owns; or
• a dedicated opt-in in the OTEL_METRICS_* family, applying to skill.name / plugin.name on cost.usage and token.usage, to the same attributes on api_request, and to mcp_server.name / mcp_tool_name.

Related, asking for the same thing: #70547 (open), and #59951 — auto-closed by the stale bot on 2026-08-02 rather than declined on the merits.

Thanks for the detailed report — reproduced on 2.1.233.

With OTel metrics enabled, a skill from a non-official (local) marketplace plugin emits skill.name: "third-party" and plugin.name: "third-party" on the cost/token counters, while a user-local skill reports its real name verbatim. No hashed identifier or marketplace attribute accompanies the redacted value, so distinct third-party skills are indistinguishable in metrics.

This redaction is intentional and documented: the monitoring docs state that third-party plugin skill and plugin names are replaced with "third-party" for privacy, while built-in, bundled, user-defined, and official-marketplace names appear verbatim. So this is working as designed today, and we're treating the ask — a stable hashed per-skill identifier (or an opt-in to emit the real name, as some log events already support via OTEL_LOG_TOOL_DETAILS=1) — as a feature request rather than a bug.

It's a reasonable ask: a salted hash would keep names private while letting deployments distinguish and cost-attribute their third-party skills. Leaving this open as an enhancement request.

🤖 Generated with Claude Code

To give another data point - we're hitting this with a client we're working with on adopting Claude Code, they have a private / internal self-hosted marketplace and want to measure skill adoption over time but skill.name collapsing to third-party makes every one of our skills indistinguishable, so per-skill adoption is unmeasurable.

OTEL_LOG_TOOL_DETAILS=1 is dangerous as it leaks other information due to enabling full_command, file_path, tool_parameters and tool_input across all tools. Enabling fleet-wide command and prompt logging to recover a skill name isn't a trade we can make, so we have no path to attribution at all.

The redaction is also asymmetric: an official-marketplace skill is named verbatim, the same skill vendored into an internal marketplace is not - both names are our own strings going only to our own collector, which the docs confirm is never sent to Anthropic.

Either fix works for us:

• A marketplace allowlist, or a names-only flag, so an operator can opt their own marketplace in without enabling command and prompt logging.
• #85555 - surfacing skill frontmatter on skill_activated.

Related, all closed by the stale bot: #70547, #59951, #71639.