[FEATURE] Native OTLP Trace/Span Export for Claude Code

Preflight Checklist

• [x] I have searched existing requests and this feature hasn't been requested yet
• [x] This is a single feature request (not multiple features)

Problem Statement

Claude Code already has a solid observability foundation — metrics and logs can be exported via OTLP and configured either through managed-settings.json (pushed via MDM) or directly via ~/.claude/settings.json, which applies across CLI and Desktop:

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_LOGS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "grpc",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "http://collector.example.com:4317"
  }
}

However, OTEL_TRACES_EXPORTER is not supported. It does not appear anywhere in the official monitoring docs, and setting it either has no effect or crashes the CLI (see #18259). Traces are simply not emitted.

Metrics answer "how much" — token totals, cost, session counts. Logs answer "what happened" — individual events as flat lines. Traces answer "why" — the full causal, hierarchical flow of a session: which tools were called, in what order, how long each step took, where it failed, and how sub-calls relate to each other.

The most widely adopted LLM observability tools — LangSmith, Langfuse, Arize, Helicone and others — are trace-first by design. Their entire data model is built around spans. These platforms do not work with metrics or logs alone. Pointing them at Claude Code's current OTLP output gives them nothing meaningful to display.

Proposed Solution

Honor OTEL_TRACES_EXPORTER=otlp and OTEL_EXPORTER_OTLP_ENDPOINT per the OpenTelemetry spec, and emit spans for:

• Session start/end (root span)
• Tool and skill invocations (name, duration, success/failure)
• MCP server calls
• Model API requests (token counts, latency, model used)
• Errors and retries

This would slot directly into the existing settings.json and managed-settings.json delivery mechanisms — no new distribution infrastructure needed.

Alternative Solutions

The community has found partial workarounds, but none are viable for broad organizational adoption:

1. Wrap the Anthropic SDK manually using a platform's instrumentation SDK — only works for teams building on the API directly, not for Claude Code users.
2. Deploy a middleware proxy (LiteLLM, Portkey, etc.) — adds infrastructure complexity, requires network routing changes, and breaks on every Claude Code update.
3. PreToolUse hooks — fragile custom scripts that don't expose full span data (e.g. skill names aren't passed as parameters) and require per-user installation.

None of these work for non-technical teams — legal, finance, operations — who cannot deploy proxies or maintain scripts.

Priority

Critical - Blocking my work

Feature Category

Configuration and settings

Use Case Example

1. Skill evaluation — An enterprise team deploys custom skills across departments. There is no way to measure which skills are invoked, how often, or whether they produce good outcomes. With trace export, every skill invocation becomes a span that flows into LangSmith or Langfuse for evaluation.

1. Cost attribution — Trace-level data enables per session, per tool call, per user, per team cost breakdown — not just org-level totals from metrics.

1. Agent debugging — A non-technical team reports that a workflow is slow. Without traces, there is no way to identify which tool call or MCP server is the bottleneck. With traces, the full execution tree is visible in any OTLP-compatible backend.

1. Compliance and audit — A regulated industry team needs a causal, ordered record of what the agent accessed and in what order. Flat logs are insufficient; traces provide the full hierarchical timeline.

1. Cross-team observability — IT configures a central OTLP collector via managed-settings.json. Engineering, legal, and finance all use Claude Code and their activity flows into the same dashboard automatically, with zero per-user setup.

Additional Context

Related issues:

• #18259 — CLI crashes when OTEL_TRACES_EXPORTER=none is set
• #35319 — Skill invocation tracking via OTEL
• #32364 — OTel support missing for Claude Code on the Web
• #13803 — OTel monitoring broken in recent versions