[FEATURE] Support for exporting OTel Traces

Resolved 💬 3 comments Opened Oct 15, 2025 by smoorjani Closed Oct 19, 2025

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

Today, monitoring claude code only supports OTel metrics and logs. While this is incredibly useful for ops health (e.g., cost tracking, tool usage failures, etc), it makes observability of what Claude Code is doing difficult, in addition to evaluating agents built on top of Claude Code or the Claude Agents SDK. Note that this proposal does not require thinking tokens and the internals (e.g., system prompts) of Claude to be traced (while it would be nice), rather just the interactions with the user as well as tool calls.

Proposed Solution

# 1. Enable telemetry
export CLAUDE_CODE_ENABLE_TELEMETRY=1

# 2. Choose exporters
export OTEL_TRACES_EXPORTER=otlp       # Options: otlp, prometheus, console

# 3. Configure OTLP endpoint (for OTLP exporter)
export OTEL_EXPORTER_OTLP_PROTOCOL=grpc
export OTEL_EXPORTER_OTLP_ENDPOINT=http://localhost:4317

# 3. Alternative configuration of just the traces endpoint
export OTEL_EXPORTER_OTLP_TRACES_PROTOCOL=http/protobuf
export OTEL_EXPORTER_OTLP_TRACES_ENDPOINT=http://metrics.company.com:4318/traces

# 4. Set authentication (if required)
export OTEL_EXPORTER_OTLP_HEADERS="Authorization=Bearer your-token"

# 5. For debugging: reduce export intervals
export OTEL_TRACES_EXPORT_INTERVAL=10000  # 10 seconds (default: 60000ms)

# 6. Run Claude Code
claude

Alternative Solutions

Most tracing solutions either intercept network traffic or use the transcript jsonl files to recreate the trace. Both are brittle and undocumented/not officially supported. At the end of the day, these are hacks to get around the lack of OTel support.

Priority

Medium - Would be very helpful

Feature Category

Other

Use Case Example

I anecdotally notice Claude is using a lot more tokens with my new command /command. I could
a) retry all the commands and hope that I can reproduce the issue
b) use my OTel traces to diagnose the issue

I can also run evaluations on top of (b) after I make a prompt change to /command to systematically ensure my fix actually works before I deploy it out to my users.

Additional Context

_No response_

View original on GitHub ↗

This issue has 3 comments on GitHub. Read the full discussion on GitHub ↗