[BUG] Claude Desktop Code-tab sessions send an invalid bearer on OTLP exports to the Claude apps gateway (invalid_token), while Cowork from the same Desktop succeeds

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?

With Claude Desktop signed in through a self-hosted Claude apps gateway (gateway is also the telemetry endpoint, telemetry.forward_to set), every OTLP export from Desktop Code-tab sessions is rejected by the gateway with reason: "invalid_token" on both /v1/metrics and /v1/logs. No service.name="claude-code-desktop" data reaches the collector.

At the same time, from the same Desktop instance and the same signed-in user:

• Cowork telemetry is accepted and arrives at the collector (service.name="cowork")
• Inference from the Code tab works normally
• Terminal CLI sessions (/login to the same gateway) export telemetry normally (service.name="claude-code")

So the Code-tab session is attaching some bearer to its OTLP exports (this is not the missing_token case of #82092), but not one the gateway accepts.

What Should Happen?

Desktop Code-tab sessions should authenticate their OTLP exports with a credential the gateway accepts — the same way Cowork sessions already do — so that claude-code-desktop metrics and logs are relayed to telemetry.forward_to.

Error Messages/Logs

Gateway log (identifiers redacted). Cowork exports in the same window are accepted; these rejections line up with Code-tab activity:

{"ts":"2026-10-02T04:31:57.149Z","evt":"auth.denied","reason":"invalid_token","path":"/v1/logs","client_ip":"<redacted>"}
{"ts":"2026-10-02T04:31:57.162Z","evt":"auth.denied","reason":"invalid_token","path":"/v1/metrics","client_ip":"<redacted>"}
{"ts":"2026-10-02T04:33:08.439Z","evt":"auth.denied","reason":"invalid_token","path":"/v1/metrics","client_ip":"<redacted>"}
{"ts":"2026-10-02T04:34:21.339Z","evt":"auth.denied","reason":"invalid_token","path":"/v1/logs","client_ip":"<redacted>"}
{"ts":"2026-10-02T04:34:21.354Z","evt":"auth.denied","reason":"invalid_token","path":"/v1/metrics","client_ip":"<redacted>"}

(gateway 2.1.287; the same pattern was logged on 2.1.285 earlier the same day.)

Bootstrap itself succeeds and supplies the OTLP settings:

{"evt":"desktop_bootstrap.serve","sub":"<redacted>","email":"<redacted>","policy_index":0}

Desktop log (~/Library/Logs/Claude-3p/main.log):

[custom-3p] bootstrap supplied config overlay { fields: [ 'inferenceGatewayBaseUrl', 'otlpEndpoint', 'otlpProtocol', 'otlpResourceAttributes', 'otlpContentCapture', 'coworkTabEnabled', 'isClaudeCodeForDesktopEnabled', 'chatTabEnabled', 'inferenceModels', ... ] }
Desktop OTLP event export enabled { ... }
[custom-3p] Credentials loaded from managed config { provider: 'gateway', mcpServerCount: 0 }
[CCD] session spawn on required_version:2.1.286:... 

Nothing in the Desktop log reports the export failure itself.

Steps to Reproduce

1. Run a Claude apps gateway (2.1.287, the current latest channel) with OIDC sign-in, telemetry.forward_to pointing at a local OTLP collector, and listen.public_url set; Claude Desktop configured via MDM bootstrapEnabled / bootstrapUrl.
2. Sign in to Claude Desktop through the gateway.
3. In the Cowork tab, send a prompt → gateway accepts the OTLP exports; service.name="cowork" metrics arrive at the collector.
4. In the Code tab, start a new session and send a prompt → the reply arrives, but the gateway logs auth.denied / invalid_token for /v1/metrics and /v1/logs; no service.name="claude-code-desktop" data arrives.

Things tried, none of which changed step 4:

• Quitting and relaunching Desktop
• Signing out of Desktop and signing back in
• Starting a brand-new Code session after re-sign-in
• Removing a stale Claude Code-credentials-<hash> keychain item (last modified weeks earlier) and relaunching
• Upgrading the gateway server from 2.1.285 to 2.1.287 (reproduces identically; Cowork exports are accepted on 2.1.287 too)

Claude Model

Not model-specific (seen with Opus and Haiku in the Code tab, via Amazon Bedrock)

Is this a regression?

Possibly. claude-code-desktop metrics did arrive through this same gateway deployment on 2026-09-17 (Desktop version at that time not recorded). None have arrived since at least 2026-09-29.

Last Working Version

Unknown (Desktop as of 2026-09-17)

Claude Code Version

• Claude apps gateway server: 2.1.287 (also reproduced on 2.1.285)
• Claude Code spawned by the Desktop Code tab: 2.1.286 (the version Desktop pins for its Code tab)
• Claude Desktop: 2.19675.0 (5706e5) 2026-10-01T05:47:14.000Z

Platform

AWS Bedrock (via a self-hosted Claude apps gateway)

Operating System

macOS 15.7.7 (arm64)

Terminal/Shell

Claude Desktop (Code tab) — not a terminal session

Additional Information

• Gateway: self-hosted on Amazon ECS Fargate, Amazon Cognito as the OIDC IdP, region ap-northeast-1. The gateway relays OTLP to an ADOT collector sidecar via telemetry.forward_to.
• Related but different: #82092 (missing_token — Desktop sending no credentials at all; largely resolved by Desktop 1.30096.1 / otlpAuthMode). Here the Code tab sends a credential, and it is rejected as invalid, while Cowork in the same Desktop instance is accepted.
• This gateway deployment has been destroyed and recreated (with a new Cognito user pool) at least once before these tests. If the Code-tab session reuses a gateway credential cached from an earlier deployment, it would explain invalid_token; signing out of Desktop does not appear to clear it.