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

Update — I found a much stronger signal than the client-version correlation in the original report. It tracks the remote sandbox image (os.version), not the client build.

Cowork remote only, last 30 days, grouped by os.version:

| Sandbox image | First seen | % rows missing user.email | Distinct sandboxes |
|---|---|---|---|
| 6.18.5-fc-v18 | 2026-08-04 | 0% | 37 |
| 6.18.5-fc-v20 | 2026-08-08 | 12% | 102 |
| 6.18.44-fc-v21 | 2026-08-17 | 80% | 87 |
| 6.18.44-fc-v22 | 2026-08-27 | 100% | 10 |

Clean monotonic degradation across four consecutive images. fc-v18 is perfect; by fc-v22 it is total.

That explains why the per-version table in the original report looked erratic — client versions were being mixed across sandbox images. Grouping by image instead removes the noise entirely. So please disregard my earlier framing of "starts at client 2.1.234": the client is not the variable.

Also worth adding: organization.id behaves exactly like the other two. On affected rows it is empty; on attributed rows from the same org and same surface it is populated. So all three identity attributes are absent as a group, while user.id and session.id are present on 100% of rows either way.

Anthropic support has confirmed via the in-product messenger that organization.id, user.account_uuid and user.email are "meant to always be populated from the user's Anthropic account and included in event attributes", and that there is no documented condition under which remote sandboxes should have them empty while local Cowork sessions do not. So this is a regression, not intended behaviour.

Adding a third affected organization, plus two controlled observations that may help narrow this.

Setup. macOS, Claude Desktop 1.40609.0, first-party Claude Team organization, OTLP endpoint configured at the organization level. Cowork sessions run in the local VM sandbox. Claude Code CLI on the same machine is unaffected and still carries identity on every record.

What we see. Cowork records arrive with no identity of any kind. Checked again today on five separate sessions: no user.email, no user.account_uuid, and no organization.id. Consistent with the reports above.

Observation 1: enduser.id and process.owner are absent too. Our collector reads both, in that order, as a fallback when user.email is missing. Neither produced a value on any Cowork record. To rule out a bug on our side we posted a synthetic OTLP log payload with service.name=cowork carrying process.owner and nothing else identifying. That one was attributed correctly. So the reader works and the fields genuinely are not on the wire. This matches the confirmation in #89483 and means the usual fallback does not rescue Cowork.

Observation 2: host-set resource attributes do not reach Cowork either. We set a custom resource attribute of our own on the host, via OTEL_RESOURCE_ATTRIBUTES, for the desktop app. It is absent from every Cowork record, while the same attribute in the synthetic payload above was stored correctly. So it is not only the identity group that is missing: nothing configured on the host appears on Cowork's records. We have not established whether that part is intended.

Timing. Our earliest nameless Cowork records are from 2026-08-18, which is consistent with the fc-v21 image date of 2026-08-17 given above. Records before that date are attributed normally.

Impact. Cowork spend cannot be attributed to a person at all right now, so it lands in an unattributed bucket. There is no per-user workaround we have found: the environment route does not reach the sandbox, and the organization-level resource attributes field is a single value for the whole company, so it cannot carry a person.

What would fix it for us. Restoring whatever the sandbox previously passed through, so that the resource attributes the desktop constructs survive into the guest. process.owner alone would be enough to put a name back on the record. Note that enduser.id does not appear to be an option for first-party organizations, so please do not treat it as the fallback here.

Happy to supply anonymised record counts or a redacted payload if that would help.

Independent confirmation of the os.version finding from a fourth organization — your sandbox-image hypothesis holds on our data, on a different collector and a different backend (self-hosted OTel Collector → ClickHouse, first-party Claude Team org).

Remote Cowork rows over 30 days, grouped by os.version:

| Sandbox image | First seen | Rows | % missing user.email |
|---|---|---|---|
| 6.18.5-fc-v18 | 2026-08-04 | 11,392 | 0% |
| 6.18.5-fc-v20 | 2026-08-07 | 41,028 | 9.3% |
| 6.18.44-fc-v21 | 2026-08-19 | 23,806 | 77.5% |
| 6.18.44-fc-v22 | 2026-08-27 | 7,988 | 64.2% |

Same four images, same first-seen dates, same monotonic climb. Our fc-v22 sits at 64% rather than your 100%, but it is the newest image and still filling out. As you found, grouping by client build produces an erratic table — we had originally reported this to support as a 2.1.234 regression and that framing was wrong for the same reason.

One addition that may narrow it further: on affected rows the missing set is not limited to the three identity attributes. app.version, os.type, os.version, host.arch, service.name, service.version, process.owner, claude.deployment_mode and workspace.host_paths are also absent on 100% of them, while the OTel resource attributes carrying those same values are intact. So the whole session-context block fails to reach log attributes, not just identity. Details and our recovery-attempt results are in #88490.