[BUG] Desktop app: OTEL_RESOURCE_ATTRIBUTES from project .claude/settings.json is never emitted (CLI on the same folder emits it)

Preflight Checklist

• [x] I have searched existing issues and this hasn't been reported yet
• [x] This is a single bug report
• [x] I am using the latest version of Claude Code

What's Wrong?

OTEL_RESOURCE_ATTRIBUTES declared in a project's .claude/settings.json is
never emitted when the session runs inside the desktop app. The same folder,
same file, same machine, opened with the CLI a few minutes later emits all of
them.

Telemetry itself works fine in both cases — events reach our collector from the
desktop app. Only the custom resource attributes are missing, which makes the
spend impossible to attribute to a project or a cost center.

A/B on one machine, same folder C:\scripts\<PROJECT>, 40 minutes apart:

| session | run by | os | terminal.type | version | project | app_code | owner_team | stack |
|---|---|---|---|---|---|---|---|---|
| 11:17 UTC | desktop app | windows | non-interactive | app 1.49585.0 (CC 2.1.260) | — | — | — | — |
| 11:57 UTC | CLI in VS Code | windows | vscode | 2.1.263 | ✅ | ✅ | ✅ | ✅ |

The file, unchanged between the two runs:

{
  "enabledPlugins": { "superpowers@claude-plugins-official": true },
  "env": {
    "OTEL_RESOURCE_ATTRIBUTES": "project=<PROJECT>,stack=<STACK>,owner_team=<TEAM>,app_code=<APP-CODE>"
  }
}

At scale, over 3 days on our collector (one organization, Team plan):

| service.name | events | distinct resource-attribute key sets | events carrying project |
|---|---:|---:|---:|
| claude-code | ~250,000 | 5 (5 to 10 keys) | ~100,000 |
| claude-code-desktop | ~190,000 | 1 (exactly 7 keys, always) | 0 |

The desktop emitter never carries a custom resource attribute: about 25
different machines, not one variation. The seven keys are service.name,
service.version, os.type, os.version, host.arch, process.owner,
claude.deployment_mode.

A further discriminating check: 9 people emit from both, with ~84,000 tagged
CLI events and ~40,000 desktop events — zero of the desktop ones tagged.

What Should Happen?

OTEL_RESOURCE_ATTRIBUTES set in the env block of a project's
.claude/settings.json should reach the telemetry exporter the same way it
does for the CLI, and be merged with (not replaced by) the attributes the
desktop app sets for itself.

Likely Cause

#67657 documents the mechanism for managed-settings.json: the desktop app
sets OTEL variables at the OS level before exec'ing the CLI, including

OTEL_RESOURCE_ATTRIBUTES=service.name=claude-code-desktop,...

so the Node OTEL SDK initializes with the app's value, and anything the CLI
later reads from a settings file arrives after initialization. If that is the
same root cause, the project-level env block is lost for the same reason —
and additionally the app's own value would replace the project's rather
than merge with it.

We could not confirm from the client side whether the project file is read at
all: the desktop session shows no project-scoped plugin, MCP server or hook
(everything is user-install / user / dynamic), and env | grep OTEL
inside the Bash tool returns nothing — although that environment appears
filtered, since the OTLP endpoint is absent there too while export works.

Not a duplicate of

• #67339 and #46204 — telemetry not initializing at all. Here it initializes

and exports correctly; only the custom resource attributes are dropped.

• Related: #67657 (same family, managed-settings.json, endpoint lost).

Environment

• Claude Code: 2.1.260 (desktop-bundled) / 2.1.263 (CLI)
• Desktop app: 1.49585.0 · Windows 10.0.26200 (x64)
• Plan: Team, SSO
• Collector: OTLP/HTTP → OpenTelemetry collector → ClickHouse

Impact

Desktop-app sessions account for roughly 40% of our telemetry events. None can
be attributed to a project or cost center, because the only per-repository
configuration channel — the project .claude/settings.json — has no effect on
that emitter. Managed settings cannot substitute: they are org-wide and cannot
carry a per-repository tag.

Session identifiers and raw event dumps for the two runs above can be shared
privately with Anthropic support on request — we have not published them here.