[Bug] OTEL Export functionality disabled or non-functional

Bug Description
OTEL Export not working from Claude Code

Environment Info

• Platform: darwin
• Terminal: Apple_Terminal
• Version: 2.1.179
• Feedback ID: 82fef84d-cf81-495b-a67a-8a19399713ee

Errors

[]

Summary

Since v2.1.113, Claude Code's OTLP metrics/logs exporter silently no-ops. The
OTLP exporter packages are no longer compiled into the binary, so
OTEL_METRICS_EXPORTER=otlp produces zero output and zero errors. This removes the
only supported mechanism for Claude Code usage observability on the Team plan.
Pinning to the last working build (2.1.111) is not an acceptable mitigation — it
strips current model access and the current agentic harness from every engineer.

Environment

• Deployment: managed-settings.json pushed to developer workstations

(<platform: macOS via MDM / mixed — fill in>)

• Telemetry backend: jellyfish, OTLP | http/protobuf ,

endpoint <…>

• Last known-good version: 2.1.111
• Broken: 2.1.113 through latest version

Business impact

On the Team plan, OpenTelemetry is the only mechanism available to us for Claude
Code token/usage data (see "Why OTEL is our only path" below). With OTLP export
broken, we have no programmatic visibility into Claude Code usage across the
engineering org. The only known way to restore it client-side is to pin the fleet
to 2.1.111, which removes access to current models and the current agentic harness
for every developer — a non-starter for a daily-driver deployment.

Symptom (precise)

• OTEL_METRICS_EXPORTER=console → full metrics print to stdout. **Pipeline

initializes and generates data.**

• OTEL_METRICS_EXPORTER=otlp (identical env, same shell) → collector receives

zero requests; the process opens no connection to the collector; nothing
on stderr; no log file under ~/.claude; OTEL_LOG_LEVEL=debug produces no
output.

• Collector verified healthy independently — a synthetic POST to /v1/metrics

with the same credentials returns HTTP 200.