OTLP telemetry silently not emitted on v2.1.153 and v2.1.169 (macOS, interactive TUI)

Summary

OTLP telemetry (metrics + logs) is silently not emitted from interactive TUI sessions on macOS, on both v2.1.153 (stable) and v2.1.169 (latest), despite:

• CLAUDE_CODE_ENABLE_TELEMETRY=1 set and confirmed via /doctor (telemetryDisabledBy=none)
• All OTEL_* env vars correctly set in ~/.claude/settings.json
• OTLP endpoint reachable from the host (TCP ESTABLISHED via lsof, TLS handshake OK)
• The same endpoint receives HTTP 200 partialSuccess for direct curl POSTs with the same bearer token (and 401 for invalid/missing token — so auth is correctly enforced server-side)
• Other OTel emitters on the same collector pipeline (non-Claude-Code workloads) deliver normally

Receiver-side counters (receiver_accepted_log_records, accepted_metric_points) do not increment for the Claude Code client across 15+ minute interactive sessions with multiple turns.

Environment

• OS: macOS 25.5.0 (Darwin)
• Claude Code: v2.1.153 and v2.1.169 (both reproduced)
• Install method: native installer (~/.local/share/claude/versions/)
• Auto-updates channel: stable (pinned via autoUpdatesChannel)
• No project/local/managed-settings overrides of telemetry

Config (~/.claude/settings.json env)

CLAUDE_CODE_ENABLE_TELEMETRY=1
OTEL_METRICS_EXPORTER=otlp
OTEL_LOGS_EXPORTER=otlp
OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf
OTEL_EXPORTER_OTLP_ENDPOINT=https://<our-otel-collector>:4318
OTEL_EXPORTER_OTLP_HEADERS=Authorization=Bearer <redacted>
OTEL_METRIC_EXPORT_INTERVAL=60000
OTEL_RESOURCE_ATTRIBUTES=deployment.environment=production,cloud.region=ap-northeast-1,...

What we ruled out

• Server side: collector + downstream sinks proven healthy via direct OTLP injection (/v1/metrics and /v1/logs both 200, land in our SIEM and CloudWatch within seconds).
• Auth: valid token returns 200, missing/invalid returns 401. Token format Authorization=Bearer <token> is correctly parsed by the OTel SDK (confirmed via curl with Authorization: Bearer <token> header).
• Endpoint: lsof shows Claude Code holds an ESTABLISHED TCP connection to the collector's resolved IP on port 4318. NLB target groups healthy.
• Telemetry disable: /doctor reports telemetryDisabledBy=none. No managed-settings, project, or local overrides.
• Version regression: tested both v2.1.153 and v2.1.169. Both fail identically. So this is not a latest-channel-only regression.
• TLS: handshake OK, ALPN not enforced, HTTP/1.1 + protobuf returns 400 (expected — proves the path reaches the OTLP HTTP receiver).

What we cannot observe externally

• console exporter is unusable for diagnosis:
• Interactive TUI: ink patches console, so OTLP-via-console output never reaches stdout or 2> redirected files.
• Headless claude -p: process exits before flush; output is zero bytes regardless of session content.
• claude --debug does not emit any OTEL-related diagnostic lines.
• No on-disk OTEL error logs.

Asks

1. Is there a recommended SDK-level diagnostic to confirm whether the OTLP exporter is constructed and emitting on macOS interactive sessions?
2. Are there known regressions in v2.1.15x – v2.1.16x around OTLP exporter initialization for interactive TUI mode? CHANGELOG entries we found (v2.1.162 log silent-drop fix, v2.1.151 SDK/headless tracing race fix) don't match the symptom (metrics also affected, and v2.1.169 post-fix is also affected).
3. Workaround to force a telemetry flush that is observable to operators?

Happy to provide additional diagnostics (collector logs, packet captures, etc.) on request.