[BUG]

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report (please file separate reports for different bugs)
• [x] I am using the latest version of Claude Code

What's Wrong?

OTEL_* env vars deployed via remote managed settings (Claude.ai admin console enterprise policy) sync correctly to every machine but are not applied to sessions for most of our org, while non-sensitive env vars from the same env block apply fine. The gating appears to be the managed-settings trust-approval flow, which fires unpredictably mid-session, is easily missed, sometimes results in only partial application after approval, and surfaces zero diagnostics when settings are pending or unapplied.

Our published policy env block:

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS": "1",
    "FORCE_AUTOUPDATE_PLUGINS": "true",
    "OTEL_EXPORTER_OTLP_ENDPOINT": "https://otel-collector.<vendor>.example.com:443",
    "OTEL_EXPORTER_OTLP_HEADERS": "X-Vendor-Token=<REDACTED>",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "http/protobuf",
    "OTEL_METRICS_EXPORTER": "otlp",
    "MANAGED_SENTINEL": "1"
  }
}

(MANAGED_SENTINEL was added by us as a control during debugging. Endpoint/header redacted; it is a third-party SaaS OTLP collector reached over HTTPS with token auth in a custom header.)

Evidence chain:

1. Sync works: /status shows "Enterprise managed settings (remote)" in Setting sources, and ~/.claude/remote-settings.json contains ALL keys including the four OTEL_* vars.
2. Selective application: in the same session, CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS, FORCE_AUTOUPDATE_PLUGINS, and QM_MANAGED_SENTINEL are all present in the environment; all four OTEL_* vars are absent.
3. The approval prompt exists but is unreliable: one user received the "Managed settings require approval / ...could allow execution of arbitrary code or interception of your prompts and responses" prompt mid-session (presumably on the hourly sync), listing FORCE_AUTOUPDATE_PLUGINS, OTEL_EXPORTER_OTLP_ENDPOINT, and MANAGED_SENTINEL. Most users report never seeing it.
4. Inconsistent partial state: on a machine where the prompt WAS approved at some point, the sentinel and FORCE_AUTOUPDATE_PLUGINS apply but the OTEL_* keys still do not — despite appearing in the same approval list.
5. No diagnostics: /doctor reports no managed-settings or telemetry issues, /status shows no pending-approval indicator, and there is no way for a user or org admin to discover that synced settings are sitting unapplied.

Impact: org-wide engineering telemetry (usage/cost attribution) silently broken for nearly all users despite a correctly published and correctly synced policy. We are working around it by mirroring the OTEL env vars into user-scope settings, which bypasses the consent prompt entirely — arguably a worse security outcome than a reliable approval flow.

Related but distinct: #31944 (approval re-triggering / not persisting), #16383 (managed env load order), #46204 (silent telemetry init failure on managed accounts).

What Should Happen?

• Env vars present in remote-settings.json either apply, or their pending/blocked state is clearly surfaced in /status and /doctor (e.g. "3 managed settings pending approval — restart to review").
• The approval prompt appears reliably at session start when approval is pending, rather than only unpredictably mid-session.
• Approval is all-or-nothing per prompt: if a user accepts a list of keys, all listed keys apply (after restart at most).
• Approval state persists across sessions and policy syncs.
• Documented guidance for enterprise admins rolling out OTEL config via remote policy, including the approval UX their users will see.

Error Messages/Logs

No errors anywhere — that is part of the bug.

/doctor: no managed-settings or telemetry warnings (only unrelated MCP auth / plugin items)
/status: shows "Enterprise managed settings (remote)" as loaded; no pending-approval indicator

$ cat ~/.claude/remote-settings.json | jq '.env'
# contains all 8 keys including all four OTEL_* vars (verified on multiple machines)

$ env | grep -iE 'OTEL|AGENT_TEAMS|AUTOUPDATE|SENTINEL|TELEMETRY'
CLAUDE_CODE_ENABLE_TELEMETRY=1        # traced to leftover in user's own ~/.claude/settings.json, NOT managed layer
CLAUDE_CODE_EXPERIMENTAL_AGENT_TEAMS=1
FORCE_AUTOUPDATE_PLUGINS=true
MANAGED_SENTINEL=1
# all four OTEL_* vars absent

Steps to Reproduce

1. In a Claude.ai enterprise org, publish a remote managed policy whose env block contains both benign keys (e.g. MY_SENTINEL=1) and OTEL_* exporter config (endpoint, headers, protocol, metrics exporter).
2. On a member machine, wait for sync (or restart); confirm ~/.claude/remote-settings.json contains all keys.
3. Start a session; run env | grep -iE 'OTEL|SENTINEL'.
4. Observe the sentinel applied and OTEL_ absent — unless/until an approval prompt happens to fire mid-session and is accepted, and in at least one observed case the OTEL_ keys remained unapplied even after approval while sibling keys from the same prompt applied.

Claude Model

Not sure / Multiple models

Is this a regression?

Yes, this worked in a previous version

Last Working Version

Unconfirmed — suspected ≤2.1.168 (behavior appears tied to the v2.1.169 security change re: untrusted settings configuring OTEL without trust confirmation)

Claude Code Version

2.1.173 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Other

Additional Information

• Auth: Claude Team/Enterprise account (organization-managed), NOT Anthropic API key — relevant because #46204 suggests the managed/enterprise account path has distinct telemetry behavior.
• Managed settings delivery: remote policy via Claude.ai admin console only; no MDM file-based managed-settings.json on these machines (the /Library/Application Support/ClaudeCode/ path does not exist).
• Install: native installer, darwin-arm64 (Apple Silicon).
• Screenshot of the mid-session approval prompt attached.
• Diagnostic suggestions: pending-approval visibility in /status and /doctor; a claude telemetry status style command (also requested in #46204); log approval grants/invalidations somewhere debuggable.
• Happy to provide redacted remote-settings.json, timestamps, or run a bisect across versions on request.