[BUG] Cloud Cowork sessions intermittently export OTLP with no identity attributes (user.email/account_uuid/account_id/organization.id) and a fresh per-session user.id

Status Open

Reported on v2.1.238

Maintainer reply None cached

Activity 3 comments · opened Aug 21, 2026

Summary

Since ~Aug 18 2026, cloud-run Cowork sessions (cowork.surface=remote) intermittently export OTLP telemetry with no identity attributes at all: user.email, user.account_uuid, user.account_id, and organization.id are absent from every record (lifecycle events and api_request alike), and user.id is a fresh random 64-hex value per session instead of a stable identifier.

This is per-session, not per-surface: we captured two cloud sessions from the same org, same VM image, same version, minutes apart - one with the full identity block on every record, one with none.

Device-run Cowork sessions are unaffected.

Environment

First-party deployment (Team plan, org a58b3455-fdc1-405d-a437-77dca5db40aa)
Cloud sessions: service.name=cowork, service.version=2.1.238, cowork.surface=remote, os.type=linux, os.version=6.18.44-fc-v21, host.arch=amd64, terminal.type=linux
Org OTLP monitoring configured via Admin settings > Cowork (OTLP/HTTP)

Evidence: A/B pair, same org, minutes apart (2026-08-21 ~09:20 UTC)

Anonymous cloud session (session.id=7190a2c7-50ed-5fbe-b65f-4495664db632, ccr.session.id=cse_013S26jUNS9gGGtkNmkWo2pZ) - api_request record attributes, complete list:

cache_creation_tokens, cache_read_tokens, ccr.session.id, client_request_id,
cost_usd, cost_usd_micros, cowork.surface, duration_ms, effort, event.name,
event.sequence, event.timestamp, input_tokens, model, output_tokens, prompt.id,
query_source, request_id, session.id, speed, terminal.type, user.id

No user.email, no user.account_uuid, no user.account_id, no organization.id - on any record of the session (checked user_prompt, assistant_response, hook_*, mcp_server_connection, api_request). user.id was a fresh 64-hex value never seen before or since; a second cloud session by the same person ~30 min earlier had minted a different one.

Identified cloud session (session.id=e48b6104-dee6-5e0c-8e76-7474955647ec, ccr.session.id=cse_019hSUpKmXC98H5X1wsBQZT6) - same org, same service.version=2.1.238, same VM image: every record carries organization.id, user.account_id, user.account_uuid, user.email.

Per the Cowork monitoring docs, the account attributes should always be present on first-party deployments.

Not a collector artifact

Both sessions traversed the identical OpenTelemetry Collector pipeline (verified config: only a scope-based filter processor that drops whole records, plus batch - no transform/attributes/resource processors). The identity block is missing at the source.

Fleet-wide impact

We operate a usage-analytics backend (tokenspend.org) ingesting Cowork OTLP for multiple organizations. New never-seen-again 64-hex user.ids across all orgs:

baseline before Aug 18: ~5-15/day
Aug 18: 55 · Aug 19: 104 · Aug 20: 370 (across 17 orgs)

Each such session is unattributable (no stable key of any kind in the payload) and appears as a phantom "user", inflating per-org user counts by 2-4x within days. The onset pattern suggests a cloud-Cowork rollout wave.

Expected

Cloud sessions populate user.email, user.account_uuid, user.account_id, organization.id like device sessions do (and like some cloud sessions still do), or at minimum a stable per-user identifier.

Related (same failure family, other surfaces)

#57908 (web client, closed not planned)
#57026 (Windows Desktop + SSO)
#36980 (desktop entrypoint, closed stale)

View original on GitHub ↗

3 Comments

mstangret · 4 days ago

Third-party confirmation from another org, plus two details that may help narrow it.

Enterprise tier, same symptoms. Both this report and #89483 are Team plan. We see identical behaviour on an enterprise / first-party org — events carry account: enterprise, and local-surface records carry claude.deployment_mode: 1p. So this isn't scoped to Team. (Happy to share our org ID privately if it helps you look up sessions.)

Coverage. claude_code.skill_activated, 20–26 Aug 2026 UTC, exported to Datadog:

| Surface | Events | With identity |
|---|---:|---:|
| os.type:darwin (local desktop) | 813 | 813 (100%) |
| os.type:windows (local) | 154 | 154 (100%) |
| os.type:linux local, terminal.type:non-interactive | 3 | 3 (100%) |
| cowork.surface:remote | 1,352 | 136 (10%) |

The count for organization.id is exactly equal to the count for user.email on every row, so the account attributes are missing as a block here too — consistent with your A/B pair.

Daily split, remote surface only:

| Day (UTC) | Remote events | With identity |
|---|---:|---:|
| 20 Aug | 134 | 0 |
| 21 Aug | 284 | 24 |
| 22 Aug | 33 | 9 |
| 23 Aug | 49 | 7 |
| 24 Aug | 332 | 45 |
| 25 Aug | 381 | 31 |
| 26 Aug | 139 | 20 |

On the ~18 Aug onset: we can neither confirm nor refute it. Our remote-surface traffic only begins on 20 Aug, so we have no pre-18 baseline. Flagging that explicitly because the 0 on our first row is where our data starts, not an onset signal.

Version: matches your finding — not a single-build regression. Our remote events span 2.1.237–2.1.246, and every version in that range appears both with and without identity.

One refinement to @felipekona's process.owner observation. We corroborate that process.owner is absent from remote records — 0 of 1,352. But on our data it tracks OS rather than surface: it is absent from all os.type:linux records including our 3 local non-interactive Linux ones, while os.type:darwin has it on 796 of 813 and os.type:windows on 154 of 154. Our local-Linux sample is tiny (n=3), so this is suggestive rather than conclusive — but it may be a separate Linux-specific gap rather than part of this bug, and worth separating before it muddies the repro.

(The darwin 796/813 is also not 100%, which we haven't chased down and are not claiming is related.)

We also see terminal.type: linux on remote records rather than the documented non-interactive.

Impact for us: enterprise adoption reporting silently under-attributes. Any query grouping by user.email drops these events entirely unless explicitly written to bucket them, so per-person and per-team numbers read as complete while omitting ~90% of remote activity. It also cost us a misdiagnosis — see the separate issue we're filing about service.version carrying the Cowork app version on local and the Claude Code version on remote, which makes "group by version" silently mean "group by surface".

Happy to supply raw records, session.id / ccr.session.id values for identity-less sessions, or run specific queries against our data if that would help.

tanguygo · 3 days ago

I can confirm we have the same issue here. Happy to provide more information if needed.

abeerag · 3 days ago

+1 - confirming we have the same issue.

From my agent:

Fourth org confirming, with a correction to one detail in the report and a retraction of one in the thread.

Scale. 750 cloud sessions / ~28,100 events, one first-party enterprise org, 26–28 Aug:

sessions
identity block absent from every record 651
identity block present on every record 99
sessions mixing the two 0
So the A/B pair generalises exactly: it is decided once per session and never varies within one. Our identified share is 12–14% per day, in line with the 10% above.

user.id is not fresh per session — it is fresh per VM. This is the one place I'd correct the report, because it points somewhere different. Across the 651 anonymous sessions:

177 distinct user.id values, not 651.
Each value spans 2–19 session.ids (mean 3.7); none appears in only one session.
It is exactly 1:1 with ccr.session.id — 177 values against 177.
So a user.id is stable across every session.id inside one ccr.session.id, and is minted fresh for the next one. "Fresh random value per session" reads as session.id granularity, which would suggest identity is lost at session start; the real granularity suggests it is established when the VM/CCR session is created, and inherited by every session.id inside it.

Device evidence for the same conclusion. Some session-start system reminders leak the desktop device id, which lets one map devices to user.ids on 97 of the 177:

a single device carries up to 23 distinct user.id values;
no user.id value ever appears on two devices.
Strict one-way nesting: device → many user.ids, never the reverse. That is consistent with the monitoring docs, which define user.id as an "Anonymous device/installation identifier" — on a cloud session each VM is effectively a fresh installation, so it behaves exactly as documented. It is doing its job; it just was never a user key, which is why "fall back to user.id" is not a workaround for anyone reading this thread.

Versions. Extends the range above: we see 2.1.246, 2.1.247 and 2.1.248, each appearing both with and without identity (31/223, 64/484, 4/43 sessions identified). Still not a single-build regression.

Retracting the process.owner angle — @mstangret was right to flag it, and it is weaker than even that. I had it in my own notes as a remote-vs-local difference. Fleet-wide across ~3.7M Cowork records it is not a surface property at all:

surface / os records with process.owner
local, darwin 3,668,311 2,893 (0.08%)
local, windows 9,238 56 (0.6%)
remote, linux 28,105 0
It is missing from essentially everything, so its absence on remote says nothing about this bug. Worth dropping from the repro before it costs someone a day.

Onset. Can't corroborate ~18 Aug — our remote traffic only starts 26 Aug, so our first day is where our data begins, not a signal.

Impact. Same shape as reported: for this org it is $527 of cloud spend over 30 days with no attributable owner, and 177 anonymous identities against roughly 12 real people. Any per-person view either drops the spend silently or invents users, depending on how it is keyed.

Happy to run specific queries against our data if it would help narrow it.