How do you track Codex CLI usage across a team?

Route 1: OpenAI's enterprise analytics

If your organisation is on a ChatGPT enterprise workspace, three admin surfaces exist and they are not interchangeable. Workspace analytics is the interactive dashboard. The Analytics API is the programmatic version of it. The Compliance API is a different thing entirely, and OpenAI is unusually direct about the difference.

aggregated Codex usage and activity metrics for a ChatGPT workspace

It's not a raw audit-log interface.

Use the Compliance API for security, legal, and governance workflows that need auditable records. It's not an adoption or productivity dashboard.

Read those three sentences together and the shape is clear: adoption questions go to Analytics, investigation questions go to Compliance, and neither one pretends to be the other. That is a better-drawn boundary than most vendors manage, and if you are inside that workspace it is the shortest path to an answer.

Two things to plan around. The first is schema stability, which OpenAI flags itself.

Dashboard categories, fields, filters, and export formats can change independently of this page.

So build the pipeline against the API rather than against a dashboard export, and expect to revisit it. The second is coverage: this is a workspace view, and it can only contain sessions that authenticated into that workspace. An engineer running Codex CLI against a platform key, or signed into a personal account on a personal machine, is doing work that never touches your workspace and therefore never appears in your workspace analytics. Whether that describes anyone on your team is a per-machine question, and a workspace-level API is structurally unable to answer it.

Route 2: Codex CLI's own OpenTelemetry

Codex CLI can export OpenTelemetry, configured through an [otel] table in ~/.codex/config.toml. This is not documented in the CLI's config docs, so the defaults below are quoted from OpenAI's own source. They are the whole story, because every one of them is a default that decides whether you get any data at all.

let exporter = config.exporter.unwrap_or(OtelExporterKind::None);

let metrics_exporter = config.metrics_exporter.unwrap_or(OtelExporterKind::Statsig);

let log_user_prompt = config.log_user_prompt.unwrap_or(false);

The exporter kinds are none, statsig, otlp-http and otlp-grpc. The otlp-http variant takes an endpoint, optional headers, a protocol and optional TLS material, so pointing Codex at a collector you run is a handful of TOML lines per machine. Which is the catch, and it is the same catch as Claude Code: a per-machine config file that nothing distributes for you, nothing validates, and nothing tells you about when it goes missing.

Route 3: read the telemetry on the machine

The third option is to put something on the Mac that receives what the tool already emits. Synopt's agent runs an OTLP receiver bound to loopback and merges an [otel] table into ~/.codex/config.toml pointed at 127.0.0.1, preserving whatever else is in that file. It refuses to touch a config whose root or existing otel key is not a TOML table, because silently rewriting somebody's hand-rolled exporter config would be worse than doing nothing.

That gets you Codex CLI regardless of how a session authenticated, on the machines where the agent is installed, and it puts Codex events on the same timeline as Claude Code and Cursor. The scope limit is different rather than absent: agent installed, macOS only.

What you actually get per Codex event

Concretely: which tool and model, timestamps, token counts, the estimated cost the tool itself reported, the repository, branch and project, and a secret-detection verdict. Cost is worth a caveat: it is what the tool's own telemetry said, not a line from a bill, and a tool that reports no cost contributes zero rather than an estimate.

One gap is specific to Codex and we would rather you read it here than discover it in the product. Codex emits tool-decision events, but they arrive classified as meta rather than as activity, so Codex contributes no permission decisions today. In practice that means there is no Codex acceptance rate. The dashboard says so on the page itself.

Feature detail varies by tool: Claude Code (tools + permission decisions), Cursor (tools + subagents), Codex (tools only: no decisions yet). Copilot/ChatGPT report no feature detail.

Which route should you pick?

You are an OpenAI enterprise workspace, Codex is the only AI tool in the building, and you want adoption numbers: use the Analytics API and stop. It is included, it is aggregated for you, and it needs nothing installed on anybody's laptop. Adding an endpoint agent to answer a question your vendor already answers is a poor trade.

The calculus changes on two conditions. If engineers also run Claude Code or Cursor, the workspace API can never see them and you are back to stitching vendors together. And if you need to know what happened on a machine (which repository, which branch, whether a credential went into a prompt) then a workspace-scoped aggregate is the wrong altitude for the question.