[BUG] Desktop app ignores OTEL_SERVICE_NAME and OTEL_RESOURCE_ATTRIBUTES from project .claude/settings.json

What's Wrong?

The desktop app's built-in agent does not apply OTEL_SERVICE_NAME or OTEL_RESOURCE_ATTRIBUTES from the project's .claude/settings.json, even though it does apply CLAUDE_CODE_ENABLE_TELEMETRY and OTEL_EXPORTER_OTLP_ENDPOINT from the very same env block (telemetry is exported normally to the configured collector, so the file is clearly being read).

The CLI, run in the same directory with the same settings file, applies all of them correctly.

We set OTEL_RESOURCE_ATTRIBUTES=project=<id> per repository so Claude Code token/cost telemetry can be attributed to the right internal initiative (governance / chargeback). Metrics from desktop-app sessions arrive with no project attribute at all, so that spend cannot be attributed to any project.

Measured on our collector over 7 days: 27 desktop sessions / 411 datapoints, none carrying project; 90 VS Code sessions / 54,383 datapoints carrying project as expected.

What Should Happen?

Both clients export the resource attributes configured in the project's .claude/settings.json:

• service.name = the value of OTEL_SERVICE_NAME
• a project resource attribute from OTEL_RESOURCE_ATTRIBUTES

i.e. the desktop app should honor the same env block the CLI honors.

Error Messages/Logs

# Metric dimensions from a DESKTOP session (project attributes missing):
service.name         = claude-code-desktop     <-- expected: value of OTEL_SERVICE_NAME
terminal.type        = non-interactive
project              = <absent>                <-- expected: MY-PROJECT
instrumentationlibrary.name/version = com.anthropic.claude_code / 2.1.271

# Metric dimensions from a CLI session, same folder, same settings file:
service.name         = my-service              <-- correct
terminal.type        = mingw64
project              = MY-PROJECT              <-- correct

Steps to Reproduce

1. In a project folder, create .claude/settings.json:

``json
{
"env": {
"CLAUDE_CODE_ENABLE_TELEMETRY": "1",
"OTEL_METRICS_EXPORTER": "otlp",
"OTEL_EXPORTER_OTLP_PROTOCOL": "http/protobuf",
"OTEL_EXPORTER_OTLP_ENDPOINT": "https://your-otel-collector.example.com",
"OTEL_SERVICE_NAME": "my-service",
"OTEL_RESOURCE_ATTRIBUTES": "org.name=acme,deployment.environment=dev,project=MY-PROJECT"
}
}
``

1. Open that folder in the Claude desktop app (Code tab) and send any prompt.
2. Inspect the metrics received by the collector: they arrive (endpoint honored), but with

service.name=claude-code-desktop and no project attribute.

1. In the same folder, from a terminal, run claude -p "ok".
2. Inspect the metrics again: service.name=my-service and project=MY-PROJECT are present.

Note: no environment variables are set at the OS level in either case; the only source of
configuration is the project's .claude/settings.json.

Claude Code Version

2.1.275 (Claude Code CLI); desktop app 2.110.1 (instrumentation 2.1.271)

Platform / OS / Terminal

Anthropic API / Windows / Claude desktop app

Additional Information

Workaround attempted and rejected

Setting OTEL_RESOURCE_ATTRIBUTES as an OS-level (user scope) environment variable is not a viable
workaround: we verified that an inherited environment variable overrides the per-project
.claude/settings.json. A global value would label every repository with the same project, which
defeats the purpose. (Secondary question: is that precedence intended? We would expect project
settings to take precedence over an inherited environment variable.)

Questions

1. Is the desktop app expected to ignore OTEL_SERVICE_NAME / OTEL_RESOURCE_ATTRIBUTES from project settings? If so, is that documented?
2. Is there a supported way to set OTel resource attributes per project for desktop-app sessions?
3. If this is a bug, is there a workaround we can adopt in the meantime?

Happy to provide more collector-side details if useful.