[BUG] Cowork remote sandboxes omit user.email / user.account_uuid / organization.id from OTel; local desktop sends them

Summary

On a Claude Teams plan with OpenTelemetry export enabled, Cowork remote
sandbox sessions emit metrics and traces with the user-identity resource
attributes empty. The same client version running as a local Cowork session
sends them on every row.

The result is unattributable spend: cost and token metrics arrive with no user,
so per-person reporting silently under-counts and the volume lands in an
"unknown" bucket. Over the last 14 days that bucket is 54% of all Cowork rows.

The decisive comparison

Identical client versions (2.1.245 and 2.1.246), same org, same collector, last
14 days. Percentage of rows where each attribute is present:

| Attribute | cowork.surface: remote | local Cowork |
|---|---|---|
| user.email | 9% | 100% |
| user.account_uuid | 9% | 100% |
| organization.id | 9% | 100% |
| user.id | 100% | 100% |
| session.id | 100% | 100% |

Sample size: 6,232 remote rows, 177 local rows.

The three identity attributes fail together as a group. The machine and session
attributes never fail. That pattern suggests the remote sandbox never receives
the authenticated user context, rather than one attribute being dropped on the
way out.

Not a clean version regression

First seen 2026-08-17 on 2.1.234, and it is intermittent per version — which
is why I don't think this is a client code change:

| Version | remote rows | % rows missing user.email |
|---|---|---|
| 2.1.231 | 4,473 | 0% |
| 2.1.233 | 2,936 | 0% |
| 2.1.234 | 1,411 | 9% |
| 2.1.235 | 1,105 | 20% |
| 2.1.236 | 256 | 0% |
| 2.1.237 | 2,997 | 73% |
| 2.1.238 | 1,571 | 37% |
| 2.1.239 | 91 | 0% |
| 2.1.241 | 2,081 | 78% |
| 2.1.245 | 3,355 | 94% |
| 2.1.246 | 2,877 | 87% |
| 2.1.247 | 2,306 | 94% |
| 2.1.248 | 186 | 100% |
| 2.1.250 | 68 | 100% |

The ratio climbing unevenly across versions, with clean versions in between,
looks more like a sandbox image or infrastructure rollout than a client build.

Scope — Cowork remote only

Last 14 days, rows with an empty user.email:

| service.name | rows | % missing email |
|---|---|---|
| claude-code (CLI) | 99,377 | 0% |
| claude-code-desktop | 41,789 | 0% |
| cowork | 23,970 | 54% |

CLI and desktop are unaffected. Within Cowork, only cowork.surface: remote.

What the affected rows do carry

A representative resource/attribute set from an affected row, values removed:

service.name       = cowork
service.version    = 2.1.246
cowork.surface     = remote
instrumentationlibrary.name = com.anthropic.claude_code
user.id            = <64 hex chars, present>
session.id         = <uuid, present>
ccr.session.id     = <cse_… id, present>
os.type            = linux
terminal.type      = linux
user.email         = ""      <-- empty
user.account_uuid  = ""      <-- empty
organization.id    = ""      <-- empty

Why user.id is not a workaround

user.id is present but cannot substitute for the email:

• It is per-machine/sandbox, not per person — identified users average ~4

distinct values each.

• Across 90 days, 0 of 261 distinct user.id values ever appear on a row

that also has an email. There is no overlap to build a mapping from.

• Grouping by it would invent people who don't exist.

Expected vs actual

Expected: a remote Cowork session exports the same identity resource
attributes as the local surface, so OTel consumers can attribute usage per user.

Actual: user.email, user.account_uuid and organization.id are empty on
~91% of remote-sandbox rows, and the proportion has been rising since 2026-08-17.

Environment

• Claude Teams plan, OpenTelemetry export enabled org-wide via managed settings
• OTLP → self-hosted OpenTelemetry Collector → Azure Monitor
• Affected client versions: 2.1.234 through 2.1.250
• Unaffected on the same collector: Claude Code CLI, Claude Code desktop, local Cowork

Happy to provide privately

Specific ccr.session.id values, user.id hashes, and exact timestamps for
affected sessions — these identify our sessions and machines, so I have not put
them in a public issue. Say where to send them.