[BUG] OTEL_METRICS_EXPORTER=otlp silently no-ops in 2.1.113 — OTLP exporter packages not bundled

Found 1 possible duplicate issue:

1. https://github.com/anthropics/claude-code/issues/32699

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

OTEL_METRICS_EXPORTER=otlp silently no-oping in 2.1.113 — because the OTLP exporter packages are not bundled in the native binary — is the same class of regression as the HTTP MCP timeout config (#50289) and the plugin cache wipe (#48985): the native binary transition from 2.1.112 to 2.1.113 changed what Node.js packages are included in the bundle, and the OTLP exporter was not brought along.

This is a significant observability regression for any organization that relies on OTEL metrics for production monitoring of Claude Code usage. The metrics export appears to work (no error) but produces no data — exactly the kind of silent failure that is hardest to catch in production.

The two-part fix:

1. Bundle the missing OTLP exporter packages. The native binary needs @opentelemetry/exporter-metrics-otlp-grpc (for gRPC/protobuf) or @opentelemetry/exporter-metrics-otlp-http (for JSON over HTTP) to be included. These are not in the current bundle.

1. Fail loudly if a configured exporter cannot be loaded. If OTEL_METRICS_EXPORTER=otlp is set but the OTLP package is not available, Claude Code should log an error: "OTLP metrics exporter configured but package not available — metrics will not be exported." Silent no-op is unacceptable for a monitoring configuration.

Workaround while the fix is deployed: If you can use OTEL_METRICS_EXPORTER=console instead, metrics will be logged to stdout/stderr. Less useful for production but confirms OTEL is configured correctly.

Related: #49893 (add OTEL effort tracking) and #50416 (expose full tool call details) — the overall OTEL observability for Claude Code is a work in progress, and this regression is a significant setback for it.

Confirming this on 2.1.111 and inside the Cowork VM — this is also the root cause of #39471

Re-ran @JuanNephrota's exact strings methodology against an older Cowork-bundled binary and against a live Cowork VM session. Two data points worth adding to this issue:

1. The regression is older than 2.1.113. @0xbrainkid suggested the bundling gap was introduced by the 2.1.112 → 2.1.113 native-binary transition. The same pattern is present in 2.1.111 — so whatever the cutover was, it happened earlier (or the OTLP transport packages were never bundled in the native binary at all).
2. This is the root cause of #39471 (Cowork OTLP monitoring not emitting events). Multiple orgs in that thread (Datadog, ADOT/X-Ray, Azure App Insights, Sumo Logic, custom collectors) report the exact same "config accepted, zero requests fire, no error surface" pattern. Cowork has no alternative observability surface (Audit Logs, Compliance API, and Data Exports do not cover Cowork sessions per the docs), so this bug is the blocker for every org trying to monitor Cowork.

---

Binary under test

• Path: ~/Library/Application Support/Claude/claude-code-vm/2.1.111/claude
• file: ELF 64-bit LSB executable, ARM aarch64, version 1 (SYSV), dynamically linked, for GNU/Linux 3.7.0, BuildID[sha1]=7184009e379dd1270157ebc863f106f3bdd1a40e, not stripped
• SHA256: 99376866bf7ec367142d3be548c17184a79f30a97318441ee9a00f78e51246e7
• Size: 236,128,832 bytes
• Baked version string in binary: VERSION:"2.1.111", ... PACKAGE_URL:"@anthropic-ai/claude-code"
• Host: Claude Desktop 1.3883.0, macOS Apple Silicon (the Cowork SDK version is pinned by the Desktop app release; "2.1.111" is baked directly into app.asar)

Strings evidence on 2.1.111 (identical pattern to 2.1.113)

$ strings -a <bin> | grep -oE '@opentelemetry/[a-z0-9._/-]+' | sort -u
@opentelemetry/api

$ strings -a <bin> | grep -oE 'exporter-[a-z-]+-otlp-[a-z-]+' | sort -u
(no output)

$ strings -a <bin> | grep "Cannot destructure property 'OTL"
Cannot destructure property 'OTLPMetricExporter' from null or undefined value
Cannot destructure property 'OTLPLogExporter' from null or undefined value
Cannot destructure property 'OTLPTraceExporter' from null or undefined value

$ strings -a <bin> | grep -oE 'OTLP[A-Za-z]+(Exporter|Delegate|Transport|Config)' | sort -u
OTLPExportDelegate
OTLPExporterConfig
OTLPLogExporter
OTLPMetricExporter
OTLPTraceExporter

$ strings -a <bin> | grep -oE '[A-Za-z]+MetricExporter|[A-Za-z]+LogExporter' | sort -u
ConsoleMetricExporter
InMemoryMetricExporter
OTLPLogExporter
OTLPMetricExporter
getOtlpLogExporter

$ strings -a <bin> | grep -E '^claude_code\.' | sort -u
claude_code.active_time.total
claude_code.code_edit_tool.decision
claude_code.commit.count
claude_code.cost.usage
claude_code.hook
claude_code.interaction
claude_code.lines_of_code.count
claude_code.llm_request
claude_code.pull_request.count
claude_code.session.count
claude_code.token.usage
claude_code.tool
claude_code.tool.blocked_on_user
claude_code.tool.execution

The full OTLP protobuf schema (opentelemetry.proto.{trace,metrics,logs,common,resource}.v1.*) is also compiled in, and the dynamic-require code fragment matching your root-cause hypothesis is observable in the binary text:

else if (O === "otlp") {
  let z = process.env.OTEL_EXPORTER_OTLP_METRICS_PROTOCOL?.trim()
       || process.env.OTEL_EXPORTER_OTLP_PROTOCOL?.trim(),
      Y = uU8();
  switch (z) {
    case "grpc": {
      let { OTLPMetricExporter: H } = await Promise.resolve().then(() => I(Mc7(), 1));
      K.push(new H);
      break;
    }
    case "ht...

Mc7() resolves to null → destructure throws → surrounding try/catch swallows → zero requests fire. Exactly your root-cause hypothesis.

Cowork VM runtime confirmation (new signal)

Ran the console-exporter test inside an active Cowork session (host: Claude Desktop 1.3883.0, macOS Apple Silicon; VM env: CLAUDE_CODE_IS_COWORK=1, CLAUDE_CODE_ENTRYPOINT=local-agent):

CLAUDE_CODE_ENABLE_TELEMETRY=1 \
OTEL_METRICS_EXPORTER=console \
OTEL_METRIC_EXPORT_INTERVAL=2000 \
  claude --print "hello"

Emitted a full claude_code.session.count data point to stdout within ~89 ms with full attributes (user.id hashed, user.email, session.id UUID, terminal.type=non-interactive). So the OTel SDK initializes fine inside the Cowork VM — the failure is purely at the OTLP exporter boundary, matching the 2.1.113 behavior.

Also verified that the Admin UI → Cowork → Monitoring configuration (OTEL_EXPORTER_OTLP_ENDPOINT, OTEL_EXPORTER_OTLP_HEADERS, OTEL_LOG_USER_PROMPTS=1, protocol, etc.) does propagate into the VM claude subprocess environment. That rules out env-var propagation bugs and narrows this issue exclusively to the exporter packaging.

Impact this adds to #50567

• Cowork has no working OTLP observability today. The Admin UI surfaces Admin → Cowork → Monitoring as a first-class feature and sets expectations that it works; in practice every OTLP backend silently receives zero events. This is the root cause of #39471, where the same reproduction is reported independently against Datadog, ADOT/X-Ray, Azure Application Insights, Sumo Logic, and custom collectors.
• Cowork users cannot self-upgrade to a newer client-side CLI. The VM SDK version ("2.1.111") is baked directly into the Claude Desktop app.asar manifest and installed into ~/Library/Application Support/Claude/claude-code-vm/<version>/claude at session start. It does not track the npm CLI release channel. Any fix needs to land in a Desktop release that bumps the pinned VM SDK to a version with the OTLP exporter packages actually bundled.
• Cowork defaults OTEL_LOG_USER_PROMPTS=1. The logs signal (not just metrics) matters as much as metrics here, and OTLPLogExporter has the same destructure error baked in. A fix needs to cover all three signals.

Minor clarification for the bundle check

PrometheusExporter is bundled in the 2.1.111 binary (appeared in strings alongside ConsoleMetricExporter and InMemoryMetricExporter). For standalone-CLI users, OTEL_METRICS_EXPORTER=prometheus + a local scrape + a Prometheus-remote-write-to-OTLP bridge is a viable workaround today. Not usable for Cowork since there is no way to reach an in-VM Prometheus endpoint from the host through the egress proxy.

+1 to the suggested fix

Bundle @opentelemetry/exporter-{metrics,logs,traces}-otlp-{proto,http} and convert the silent swallow into a loud startup error ("OTLP <signal> exporter configured but package not available — telemetry will not be exported"). Silent no-op on a monitoring configuration is the worst possible failure mode.

Suggested labels to add

• area:cowork (this manifests as a Cowork blocker in addition to the standalone CLI)
• regression (confirmed present on at least 2.1.111 through 2.1.113)

+1, confirming this Cowork blocker persists on Claude Desktop
1.4758.0 (build fb266c, 2026-04-24), macOS Apple Silicon. Same
behavior as ten-jampa documented on 1.3883.0: settings persist
correctly, env vars propagate (verified via OTEL_METRICS_EXPORTER=
console-style alternative testing), but OTLP exporter never sends.
This issue blocks Cowork OTel observability for our org regardless
of which OTLP backend or endpoint we point at.

i lost two afternoons last week to this exact silent failure. had OTEL_METRICS_EXPORTER=otlp set, collector logs were empty, no errors anywhere, kept second-guessing my collector config before stracing the bun binary and seeing the require() for exporter-metrics-otlp-http getting swallowed in a try/catch. switched to OTEL_METRICS_EXPORTER=console just to confirm metrics were actually accumulating, they were. ended up giving up on otel for usage tracking and pulling the rolling 5-hour and weekly numbers straight off the claude.ai settings/usage endpoint instead, which is what anthropic actually enforces against. the silent fallback is the worst part of this bug, a thrown error on missing exporter would've saved me half a day.

same problem in 2.1.123 version

I am not able to reproduce this locally. I can not deduce from the report alone what is going on. Can you please share the specific error you are getting: run again with --debug-file /tmp/otel.log and share the lines matching grep -i "3P telemetry" /tmp/otel.log. this should give me the exact error where it is failing.

Adding org-wide evidence from a different Datadog tenant that confirms this regression and helps narrow the package-bundling hypothesis.

Setup

• Backend: Datadog EU OTLP intake (https://otlp.datadoghq.eu/v1/metrics)
• Plain http/protobuf, no mTLS
• ~26 distinct users in our tenant, mix of Claude Code versions

Last 24h claude_code.session.count grouped by version resource attribute

| version | sessions emitted (24h) |
|----------|-----------------------:|
| 2.1.118 | 2 |
| 2.1.119 | 0 |
| 2.1.120 | 0 |
| 2.1.121 | 0 |
| 2.1.122 | 0 |
| 2.1.123 | 0 |
| 2.1.126 | 0 |

So in our tenant, plain HTTP/protobuf (no mTLS) does still work on 2.1.118 but is silent on every 2.1.119+ build observed (including 2.1.126). #52353 reports plain-config also broken on 2.1.118 with mTLS — our data is the dual: 2.1.118 still works for the non-mTLS code path. That's consistent with a packaging/bundling issue where some OTLP exporter modules survive the bundling change and others don't, and the breakage widens further at 2.1.119.

Debug log on 2.1.126 (anonymized)

claude --debug produces these [3P telemetry] lines:

[3P telemetry] Waiting for remote managed settings before telemetry init
[3P telemetry] Remote managed settings loaded, initializing telemetry
[3P telemetry] isTelemetryEnabled=true (CLAUDE_CODE_ENABLE_TELEMETRY=1)
[3P telemetry] getOtlpLogExporters: types=[], protocol=http/protobuf, endpoint=undefined
[3P telemetry] Created 0 log exporter(s)

No getOtlpMetricExporters line, no Created N metric exporter(s) line — i.e. the metric-exporter init branch never executes (or throws inside the silent try/catch and is swallowed). This matches the bundled-package hypothesis in the OP: the metric OTLP exporter dynamic require fails, the catch swallows, and that branch silently no-ops.

Other diagnostics

• DD-API-KEY validated independently (curl … /v1/metrics --data-binary '' → 400 Payload is empty) — credentials and endpoint healthy.
• All OTEL env vars are present in Claude's process environment (printenv | grep OTEL), so this isn't an env-var availability issue.
• No local managed-settings.json; remote managed settings load successfully before telemetry init.

Asks

• Add a fail-loud path: when the OTLP exporter package(s) can't be loaded, emit at least one WARN-level [3P telemetry] line (not silently swallowed in try/catch). Right now this is debuggable only by side channels (network captures or watching backend ingestion) which is brutal at fleet scale.
• Confirm whether the bundling fix shipped in any 2.1.x release; we'd be happy to retest.
• Workaround we landed for now: pin to 2.1.112 / 2.1.118 depending on whether mTLS is in use.

(Filed our duplicate as #56021; closing that and pointing here.)

Hi — any update on this? Still reproducing on v2.1.143.
Could someone from Anthropic confirm whether a fix is being tracked? Thanks!
@JuanNephrota @mhegazy @andersenleo @ten-jampa @AZVGBND

Update from our side:
Confirmed working on v2.1.143 with mTLS after switching
from OTEL_EXPORTER_OTLP_CLIENT_CERTIFICATE / _CLIENT_KEY
to CLAUDE_CODE_CLIENT_CERT / CLAUDE_CODE_CLIENT_KEY
(the correct vars for http/protobuf per the updated mTLS docs).

Still not working for us - sending OTEL to Datadog :/

Ping! Anyone with an update, or successfully working metrics in Claude Code?

Alright - I can verify metrics works for us now. And might have been working all along.
We accidentally used a stale Datadog API Key 🙈. So - this works for us now.

Can any one confirm this actually is working, we are running into the same issue on the latest version of Claude Code, console export Works, so we know that is valid, Manual calls using claude work, so we know thats not the issue, but automatic OTLP exports do Nothing