3P OpenTelemetry telemetry not initializing on enterprise/managed accounts (Windows)
Summary
OpenTelemetry 3rd-party telemetry export does not initialize on enterprise/managed accounts when running Claude Code on Windows. Environment variables are correctly set and visible in the Claude Code Node.js process, but no OTLP connections are established and no data is exported — not even with console exporters.
Environment
- Claude Code version: 2.1.98 (
@anthropic-ai/claude-code) - Platform: Windows 11 Pro 10.0.22631
- Node.js: v25.3.0
- Shell: Git Bash (via PowerShell terminal)
- Account type: Enterprise/managed (OAuth authentication)
- Docker: Rancher Desktop (containers running on WSL2)
Configuration
Exact configuration as documented at https://code.claude.com/docs/en/monitoring-usage:
export CLAUDE_CODE_ENABLE_TELEMETRY=1
export OTEL_METRICS_EXPORTER="otlp"
export OTEL_LOGS_EXPORTER="otlp"
export OTEL_TRACES_EXPORTER="otlp"
export OTEL_EXPORTER_OTLP_PROTOCOL="grpc"
export OTEL_EXPORTER_OTLP_ENDPOINT="http://localhost:4317"
Also tested with:
http/jsonprotocol on port 4318http/protobufprotocol on port 4318consoleexporters (no output produced)OTEL_METRICS_EXPORTER=none(logs only)- Various combinations of the above
Verified conditions
1. Environment variables ARE set in the Claude Code process
Confirmed via PowerShell GetProcessById().StartInfo.EnvironmentVariables:
CLAUDE_CODE_ENABLE_TELEMETRY = 1
OTEL_METRICS_EXPORTER = otlp
OTEL_LOGS_EXPORTER = otlp
OTEL_EXPORTER_OTLP_PROTOCOL = grpc
OTEL_EXPORTER_OTLP_ENDPOINT = http://localhost:4317
2. OTel Collector is running and reachable
All containers healthy (Grafana, Loki, Prometheus, Tempo, OTel Collector). Manual OTLP requests from both curl and Node.js succeed — data arrives in Loki.
3. Claude Code never connects to the collector
Verified via Get-NetTCPConnection — the Claude Code process has zero TCP connections to ports 4317 or 4318. Only connections to Anthropic API servers (port 443).
4. Console exporter produces no output
With OTEL_METRICS_EXPORTER=console and OTEL_LOGS_EXPORTER=console, no JSON telemetry data appears in the terminal. This confirms the telemetry pipeline is never initialized, not a network/connectivity issue.
5. No managed settings file exists
Checked C:\ProgramData\ClaudeCode\managed-settings.json — directory does not exist. No MDM-deployed configuration overriding user settings.
Root cause analysis (from source code investigation)
We traced the initialization flow in the minified cli.js (v2.1.98):
Telemetry init flow
_r8() → checks Eo1() (managed account?) → waits for fu8() → cl() → J$7() → S6Y()
Managed path routing
The account's OAuth token has subscriptionType === null, causing the yF() function to return true. This routes telemetry init through the managed path, which:
- Creates a Promise (
B56) with a 30-second timeout - Attempts to fetch remote managed settings from
${BASE_API_URL}/api/claude_code/settings - After timeout or settings load, calls
cl()(applies config toprocess.env) thenJ$7()(initializes exporters)
However, something in this chain fails silently — the .catch() handler only logs internally via an opaque N() function that is not visible to the user:
fu8().then(async () => {
cl();
await J$7();
}).catch((q) => {
N(`[3P telemetry] Telemetry init failed (remote settings path): ${U6(q)}`);
// ← Error is swallowed here, user never sees it
});
Beta tracing path also blocked
The beta tracing path (h6Y()) requires a feature flag tengu_trace_lantern that is not enabled for this account:
function jJ() {
if (!(B6(process.env.ENABLE_BETA_TRACING_DETAILED) && Boolean(process.env.BETA_TRACING_ENDPOINT)))
return false;
return Q7() || h8("tengu_trace_lantern", false); // feature flag not set
}
In interactive mode, Q7() returns false (!isInteractive), and the feature flag is not set, so the beta path is never taken.
Expected behavior
With CLAUDE_CODE_ENABLE_TELEMETRY=1 and valid OTEL exporter configuration, Claude Code should export telemetry data to the configured endpoint, regardless of account type (personal, team, enterprise).
Actual behavior
No telemetry data is exported. No connections are made to the OTEL collector. Console exporters produce no output. The telemetry initialization fails silently on the managed/enterprise account path.
Steps to reproduce
- Use an enterprise/managed OAuth account (organization with
subscriptionType === null) - Set environment variables as documented
- Run
claudeorclaude --resume - Observe no OTLP connections and no console exporter output
Suggested improvements
- Surface telemetry initialization errors — at minimum via
stderror a debug log file, so users can diagnose failures - Ensure the managed settings path doesn't silently prevent telemetry init — if remote settings fail to load, telemetry should still initialize with user-provided env vars
- Add a
claude telemetry statusdiagnostic command to help users verify their telemetry configuration is working
This issue has 4 comments on GitHub. Read the full discussion on GitHub ↗