[BUG] Claude Code creates Honeycomb boards on startup using OTEL credentials

Found 1 possible duplicate issue:

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

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

This is observability-side-effect leakage at the startup credential boundary.

If Claude Code creates Honeycomb boards on startup using OTEL credentials, then telemetry credentials intended for observation are being treated as sufficient authority for a write-side product action during initialization.

Why it matters:

• startup should be the most conservative phase for side effects because users have not yet taken an explicit action inside the session
• OTEL credentials normally imply data emission/observability plumbing, not UI artifact creation in a third-party control plane
• automatic write-side behavior at startup makes it hard to distinguish intended instrumentation from accidental product mutation

I would want clarity on:

1. whether board creation is an intentional onboarding path, a regression in Honeycomb integration defaults, or a mis-scoped use of OTEL-derived identity
2. whether startup can detect existing resources and suppress creation unless the user explicitly opted into provisioning behavior
3. whether observability integrations expose a clear split between read/emit permissions and resource-creation permissions so telemetry setup cannot silently mutate external state

Startup integrations need least-surprise side-effect semantics. If OTEL credentials are enough for Claude Code to create Honeycomb boards on launch, the credential boundary is broader than users can safely assume.

@0xbrainkid agreed, "observability-side-effect leakage at the startup credential boundary" nails it.

Concrete asks on top of your three points:

1. Intent. If board creation is an intentional onboarding path, it should be gated, default off, and documented in the monitoring page. If it's a regression, revert.
2. Idempotency. Even when enabled, startup should detect existing boards and skip creation. There is no signal any such check happens today.
3. Credential separation at the enterprise layer. This does not have to be a single global flag. A cleaner shape for managed installs is a boolean in the enterprise/managed OTEL config (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 actually 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.

Least-surprise at startup is the right bar. Launching the CLI should not mutate third-party SaaS state without an explicit, separately-credentialed user action. I updated the issue body to fold this in.

I think the underlying issue is a bit different than what was described and its solution is simpler.
To send OTEL data from claude to track usage, the docs say you need to change the environment variables.
https://code.claude.com/docs/en/monitoring-usage#quick-start

For it to be an organization-wide setting you need to update settings.json in the organization settings owner's console
In that settings.json, you need to set the standard OTEL environment variables.
i.e.:
CLAUDE_CODE_ENABLE_TELEMETRY=1
OTEL_EXPORTER_OTLP_ENDPOINT=...
OTEL_EXPORTER_OTLP_HEADERS=x-honeycomb-team=some_secret
OTEL_EXPORTER_OTLP_PROTOCOL=...
OTEL_LOGS_EXPORTER=...
OTEL_METRICS_EXPORTER=...

The issue itself is that a terminal that's using claude with these settings directly (and processes spawned from such claude session) inherits those environment variables. Thus if I start my own service, e.g.: npm run start using claude, it will have those OTEL environment variables. For honeycomb's case, it can use those variables to create new datasets and push data to a collector that is supposed to be used only for claude tracking purposes.

In my local environment I would expect to have my own OTEL collector via docker compose, so instead of sending my traces/spans/logs/metrics to that collector, im sending them to the one that my team defined (for this case, honeycomb).

A solution would be rather simple, have Claude use the same environment variables, but with prefix CLAUDE, so CLAUDE_OTEL_EXPORTER_OTLP_ENDPOINT, ... etcetera.
This way if they are inherited, they won't override in any way the regular OTEL environment variables one would expect.

@bcherny does this sound reasonable?

Landed a change to strip out the env vars to avoid this from happening.

Landed a change to strip out the env vars to avoid this from happening.

Thanks for the quick work @mhegazy. In which version do you think this will ship? sorry for the insistence

Should be in v2.1.129

This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.