Monitoring Codex with Airia

Send OpenAI Codex CLI telemetry to Airia AI App Monitoring over OpenTelemetry to see Codex sessions, events, and usage metrics next to your Claude activity.

Airia AI App Monitoring ingests OpenTelemetry (OTel) telemetry from the OpenAI Codex CLI. Codex activity appears in the same AI App Monitoring page (formerly Claude Monitoring) as your Claude Code activity, with its service shown as codex. You get sessions, a per-event timeline, and a Codex metrics panel with request counts, latency, and tool calls.

This is observation, not enforcement. To route Codex traffic through Airia for DLP, guardrails, budgets, and audit, see Securing ChatGPT and Codex. The two are complementary: routing governs the traffic, and OTel monitoring records what Codex reports about its own activity.

How it works

Codex exports OTel logs and metrics to the same Airia ingest endpoint that Claude Code uses. Airia normalizes Codex events into the monitoring feed, timeline, and session views, and rolls Codex metrics up hourly.

Signal	Ingest endpoint
Logs	`<tenant API base>/v1/ClaudeCodeOtelIngest/ingest/v1/logs`
Metrics	`<tenant API base>/v1/ClaudeCodeOtelIngest/ingest/v1/metrics`

Requests authenticate with an X-API-Key header carrying an Airia API key that has the Claude OTel ingest scope.

Codex has no key setting of its own and reuses the Claude Code key. It uses the API key configured on the Claude Code tab of the setup guide. If you remove or replace that key, Codex telemetry is rejected with 401 errors while key validation is enforced.

Prerequisites

An Airia role with access to Claude Monitoring setup
An Airia API key with the Claude OTel ingest scope, set up on the Claude Code tab of the Claude Monitoring setup guide
The Codex CLI on each machine you want to monitor, with access to edit its config.toml
The Codex tab of the Claude Monitoring setup guide visible to your tenant. Codex setup is being rolled out gradually, so if you don't see the tab, contact Airia support.

Set up Codex monitoring

In Airia, open Audit → Activity → AI App Monitoring and open Setup guide.

On the Claude Code tab, select or create the API key Airia should use for OTel ingestion. The key value is shown only when it is created, so copy it then.

Open the Codex tab. It shows the config.toml to copy, and a toggle for sending prompt text.

Add the [otel] block to ~/.codex/config.toml (or %USERPROFILE%\.codex\config.toml on Windows) on each machine running Codex, replacing the placeholders:

[otel]
log_user_prompt = true

exporter = { otlp-http = { endpoint = "<tenant API base>/v1/ClaudeCodeOtelIngest/ingest/v1/logs", protocol = "json", headers = { "X-API-Key" = "<your-airia-api-key>" } } }

metrics_exporter = { otlp-http = { endpoint = "<tenant API base>/v1/ClaudeCodeOtelIngest/ingest/v1/metrics", protocol = "json", headers = { "X-API-Key" = "<your-airia-api-key>" } } }

Restart Codex, run a short session, and confirm it shows up in Claude Monitoring with the service codex.

Three details in that block matter:

protocol = "json" is required. Airia accepts OTLP over HTTP with JSON only. Protobuf and gzip-compressed requests are rejected with 415.
metrics_exporter is separate from exporter and must be set. Without it, Codex's metrics exporter defaults to OpenAI's own destination, so no metrics reach Airia.
Requests are limited to 5 MB.

The key is stored in plain text in config.toml. Treat the file like any other credential on the machine.

Attribute activity to a user

Airia attributes Codex activity by email address.

Signed in with ChatGPT: Codex reports the user's email (user.email) itself, and no extra setup is needed.
Signed in with an API key: Codex reports no email. Set this environment variable on the machine, replacing the address, so Airia can attribute the activity:

export OTEL_RESOURCE_ATTRIBUTES="[email protected]"

Airia honors the airia.user-email resource attribute. Whether the Codex CLI passes OTEL_RESOURCE_ATTRIBUTES through to its exported telemetry has not been confirmed yet, so check that the user shows up correctly after your first test session before you roll this out widely.

What appears in Claude Monitoring

Codex events appear in the monitoring feed, the event timeline, and session views under the service codex.

Codex event	How it appears
`conversation_starts`	Session start
`user_prompt`	A prompt. Text is shown only if the settings below allow it; otherwise only the prompt length.
`api_request`	A model request. Failed requests show as errors.
`sse_event`	Stream events are recorded. The individual streaming delta frames are not stored.
`websocket_request`, `websocket_event`	Websocket activity
`tool_decision`	A tool approval decision
`tool_result`	A tool result

Events Airia does not support are ignored without error, so a newer Codex release that adds events won't break ingestion.

Sessions are keyed by the Codex conversation ID. Unlike Claude Code, Codex activity is not grouped per prompt, so use the session and event views rather than the prompt view.

Prompt text and tool details

What Airia stores is controlled on both sides:

Prompt text is stored only when log_user_prompt = true in Codex and your tenant's Send prompt text setting is on. Otherwise Airia stores only the prompt length. Codex's redaction placeholder ([REDACTED]) is not stored as if it were the prompt.
Tool arguments and output follow your tenant's Send tool call details setting.

Codex metrics

Airia converts these Codex metrics into hourly rollups: codex.api_request, codex.sse_event, codex.websocket.request, codex.websocket.event, and codex.tool.call with its duration_ms histogram.

The Codex metrics panel on the Claude Monitoring page shows:

API requests, with a breakdown by status and how many failed
Request time, as a median and a p95
Tool calls, with a breakdown by tool

Keep these in mind when reading the panel:

It is tenant-wide. The panel is hidden when a user or surface filter is active, because metrics are not attributed to individual users.
The maximum range is 90 days, and metrics are kept for your tenant's data retention period.
Percentiles are approximate. They are estimated from histogram buckets.

Limitations

JSON only. Protobuf and gzip requests are rejected with 415.
Delta temporality metrics only.
No guardrails. Codex events are not evaluated against guardrails. To apply guardrails to Codex, route it through the AI Gateway as described in Securing ChatGPT and Codex.
No per-prompt grouping. Sessions are keyed by conversation.
Approximate percentiles in the metrics panel.
Tenant-wide metrics. No per-user metrics breakdown.

Troubleshooting

Nothing appears in Claude Monitoring

Confirm protocol = "json" on both exporters. A 415 response means Airia received protobuf or gzip.
Confirm the endpoint ends in /ingest/v1/logs or /ingest/v1/metrics.
Confirm the X-API-Key value is an active key with the Claude OTel ingest scope.
Restart Codex after editing config.toml.

Requests are rejected with 401

The Claude Code key may have been removed or replaced. Select or create a key on the Claude Code tab and update config.toml to match.

Events appear, but the Codex metrics panel is empty

Confirm metrics_exporter is set. Without it, Codex sends metrics to OpenAI's default destination.
Remove any user or surface filters, which hide the panel.
Metrics are rolled up hourly, so allow some time after the first session.

Events appear without a user

Users signed in with an API key send no email. Set OTEL_RESOURCE_ATTRIBUTES as described above.

Prompts show only a length

Check that log_user_prompt = true in Codex and that Send prompt text is on for your tenant.

Need help? Contact Airia support.

Monitoring Codex with AiriaNewEnterprise