codex - 💡(How to fix) Fix Include user identity in Codex OTel standard attributes [1 participants]

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.