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)
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, andorganization.idare absent from every record (lifecycle events andapi_requestalike), anduser.idis 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
a58b3455-fdc1-405d-a437-77dca5db40aa)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=linuxEvidence: 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_requestrecord attributes, complete list:No
user.email, nouser.account_uuid, nouser.account_id, noorganization.id- on any record of the session (checkeduser_prompt,assistant_response,hook_*,mcp_server_connection,api_request).user.idwas 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, sameservice.version=2.1.238, same VM image: every record carriesorganization.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
filterprocessor that drops whole records, plusbatch- 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: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.idlike device sessions do (and like some cloud sessions still do), or at minimum a stable per-user identifier.Related (same failure family, other surfaces)