Include user identity in Codex OTel standard attributes

What feature would you like to see?

Please include stable user identity attributes in Codex OpenTelemetry exports by default, especially for metrics.

For organizational usage monitoring, it is a common and expected requirement to answer questions like:

• Which users are actively using Codex?
• How much token/tool/session usage is attributable to each user?
• Which users or teams need enablement, support, or cost review?
• How can metrics be correlated with logs/traces when investigating usage or reliability?

Today, Codex OTel metrics include useful dimensions such as app.version, auth_mode, model, originator, and session_source, but they do not appear to include a stable Codex/OpenAI user identifier such as user.id, user.email, account.id, or equivalent.

This makes org-wide dashboards hard to build without adding a separate proxy/collector layer that injects identity outside Codex. That workaround is fragile because the Codex client already knows the authenticated account context.

Why this should be a default standard attribute

User-level usage segmentation is not a niche requirement for enterprise telemetry. It is one of the most basic use cases for OTel-based usage monitoring.

For comparison, Claude Code documents user/account identity as part of its standard telemetry attributes:

https://code.claude.com/docs/en/monitoring-usage#standard-attributes

Their documented standard attributes include, when available:

• organization.id
• user.account_uuid
• user.account_id
• user.id
• user.email

The same page also documents cardinality controls such as OTEL_METRICS_INCLUDE_ACCOUNT_UUID, with account UUID/account ID included by default.

Codex should have a comparable first-class identity dimension for enterprise monitoring.

Suggested behavior

At minimum, Codex OTel should include a stable, non-secret user identifier in the standard attributes for metrics, logs, and traces when authenticated, for example:

• user.id or user.account_id: stable authenticated Codex/OpenAI account identifier
• organization.id or workspace.id: stable org/workspace identifier, when available

If exposing email by default is a privacy concern, then a reasonable compromise would be:

• include a stable pseudonymous user/account ID by default
• include user.email only when available and allowed by policy, or behind an explicit config flag
• document the exact privacy/cardinality behavior

Possible config controls could mirror the existing telemetry-cardinality approach used by other coding agents, for example:

[otel]
include_user_id = true
include_user_email = false

or equivalent environment/config options.

Current workaround and why it is insufficient

I tried using standard OTEL_RESOURCE_ATTRIBUTES to inject a static user email from the shell environment, but that is not a good solution for org rollout:

• it has to be configured separately for every user/device
• it is easy to misconfigure or forget
• it may not be reflected in Codex metrics depending on exporter/collector behavior
• it duplicates identity that Codex already has through authentication

A collector/proxy can inject labels, but then the usage identity is no longer a Codex-native telemetry attribute and becomes deployment-specific glue.

Related issues

• #6390 requested additional OTel labels, but was closed as not planned due to low upvotes. This request is narrower and more fundamental: user/account identity should be part of the standard telemetry schema, not just arbitrary custom labels.
• #15905 asks for conversation.id on OTel metrics. That solves conversation-level correlation; this issue is about user/account-level attribution.

Acceptance criteria

• Codex OTel metrics include a stable authenticated user/account identity attribute by default when available.
• Codex OTel logs/traces use the same identity keys for consistency.
• The behavior is documented in the Codex OTel docs and config reference.
• If email is considered sensitive, Codex documents whether user.email is omitted, gated, or opt-in, while still providing a stable non-secret user/account ID by default.