claude-code - 💡(How to fix) Fix [BUG] Claude Code creates Honeycomb boards on startup using OTEL credentials [5 comments, 4 participants]

Summary

On startup, when OpenTelemetry is enabled via enterprise/managed settings, Claude Code appears to use the configured OTEL credentials (OTEL_EXPORTER_OTLP_HEADERS containing the Honeycomb API key) to call Honeycomb's Boards API and create dashboards/boards in the org's Honeycomb environment.

This is unexpected: the OTEL spec only defines signal export (metrics/logs/traces). Creating boards is a Honeycomb-specific control-plane action that should not be triggered by an OTLP exporter. Orgs end up with auto-generated boards they didn't ask for and have to clean up manually.

Reproduction

1. Set up Claude Code under an enterprise/managed configuration with:
   • CLAUDE_CODE_ENABLE_TELEMETRY=1
   • OTEL_EXPORTER_OTLP_ENDPOINT pointing at Honeycomb (e.g. https://api.honeycomb.io)
   • OTEL_EXPORTER_OTLP_HEADERS=x-honeycomb-team=<API_KEY> where the key has board write scope (typical for ingest+config keys used in CI/managed envs)
2. Launch Claude Code (any session that initializes telemetry).
3. Check the Honeycomb environment's Boards list. New Claude-Code-related boards appear without being requested.

Expected

Claude Code's OTEL integration should only export signals via OTLP. It should not call the Honeycomb Boards API (or any backend control-plane API) to create dashboards.

Proposed shape of the fix

The fix does not have to be a single global flag. Either of these works, in order of preference:

1. Don't reach into the backend control plane at all from OTEL setup. OTLP headers are for signal export only. If pre-built boards are useful, ship them as a separate, explicit provisioning step (e.g. claude honeycomb install-boards) that the user invokes intentionally.
2. Enterprise-level credential separation. When OTEL is configured via enterprise/managed settings, expose a boolean (something like honeycomb.allowControlPlaneWrites: false by default) that prevents Claude Code from using OTEL_EXPORTER_OTLP_HEADERS for anything other than signal export. If provisioning is desired, it should read a separate, explicitly scoped credential from managed settings or a repo-level config, never from the OTLP headers. Telemetry auth should not imply provisioning auth.
3. Opt-in env flag (e.g. CLAUDE_CODE_HONEYCOMB_INSTALL_BOARDS=1), default off, idempotent (detect existing boards and skip), documented in the monitoring page.

Whichever shape lands, the guarantee should be: launching the CLI does not mutate third-party SaaS state without an explicit, separately-credentialed user action.

Why this matters

• Enterprise orgs treat their Honeycomb workspace as managed infra. Surprise board creation by a CLI is noise at best, and at worst pollutes a curated workspace.
• The only current workaround is to fully disable telemetry (CLAUDE_CODE_ENABLE_TELEMETRY=0), which loses the actual telemetry value.
• Scoping the OTLP headers down to ingest-only on the Honeycomb side mitigates this, but most managed deployments use a broader-scope key by default, which is why credential separation needs to live on the Claude Code side too.

Environment

• Claude Code: enterprise managed install (latest)
• OTEL backend: Honeycomb (only. Datadog and others do not exhibit this since the behavior is Honeycomb-API specific)
• Telemetry enabled via org-wide managed settings

Related

• #42281 (Native OTLP Trace/Span Export)
• #53075 (Analytics docs should clarify telemetry opt-out effects)
• #46204 (3P OpenTelemetry on enterprise/managed accounts)