Skip to main content
All Codex integration capabilities

​
About

Ship Codex session telemetry to Sazabi using Codex’s built-in OTLP exporter. The Codex CLI, the Codex desktop app, and the Codex IDE extension all read the same ~/.codex/config.toml, so one [otel] section covers every Codex client on the machine. Once configured, every session emits structured events covering user prompts, tool decisions, tool results, and model API requests — no code changes to your projects required. Events include attributes like codex.user_prompt, codex.tool_decision, codex.tool_result, and codex.api_request, along with prompt, model, conversation.id, user.email, and originator. codex.tool_result also carries arguments (that tool’s full input — a shell command’s cmd/workdir, or another tool’s own parameters) and output (that tool’s result).
Enabling log_user_prompt = true exports raw prompt text, including any sensitive content typed during sessions. Only enable it when you understand the privacy implications for your team.
Tool-call content is exported regardless of log_user_prompt. Each codex.tool_result event carries arguments — that tool’s full input (for shell commands, the cmd and workdir; for other tools such as apply_patch or an MCP call, that tool’s own parameters, which can include patch contents, queries, or credentials) — and output, that tool’s result truncated around 2 KB. Codex has no flag for these, so setting log_user_prompt = false does not suppress them. Treat every tool’s inputs and results as exported, not only shell commands.

​
Prerequisites

  • The Codex CLI, desktop app, or IDE extension installed and running
  • Your Sazabi intake URL, shown above — open the log source and copy the Intake URL from its setup screen (the public key is embedded in the URL)

​
Set up in the dashboard

1

​
Add the OTLP exporter to your Codex config

Add these lines to ~/.codex/config.toml. If [otel] already exists, set log_user_prompt and exporter inside it, replacing any existing values, instead of adding a second [otel]. Codex ignores [otel] in a project’s .codex/config.toml, so it must go in the file in your home directory.
~/.codex/config.toml
Replace <your intake URL> with the intake URL shown above. Codex requires the full logs URL including the /v1/logs path suffix — it does not append the path itself.The exporter is written as an inline table on purpose: Codex writes its own [otel] table that way, and a second [otel] header or an [otel.exporter.otlp-http] header beneath an inline exporter is a TOML error that stops Codex from starting.Leave the metrics exporter at its default. Codex metrics are not ingested yet; pointing them at Sazabi only ships traffic that intake discards.
2

​
Restart Codex

Codex loads its configuration at startup. Start a new CLI session, quit and reopen the desktop app, or restart your editor for the IDE extension so the new settings take effect.

​
Roll out to your whole organization

To turn telemetry on for every developer without editing each machine’s ~/.codex/config.toml, put the same [otel] section in Codex’s admin-enforced requirements.toml. Codex applies these values over each developer’s own [otel] settings in the CLI, the desktop app, and the IDE extension, so developers cannot turn the export off or point it elsewhere.
requirements.toml
Distribute the file with your device management tooling:
  • macOS and Linux — /etc/codex/requirements.toml.
  • Windows — %ProgramData%\OpenAI\Codex\requirements.toml.
  • macOS with MDM — base64-encode the file (no line wrapping) and deliver it in a configuration profile under the com.openai.codex preference domain, key requirements_toml_base64. This works with tools such as Jamf Pro, Fleet, and Kandji.
log_user_prompt = false keeps prompt text out of your logs; set it to true only if your policy allows storing prompts. Tool-call content is exported either way. Every Codex client picks up the managed values the next time it starts. Older deployments may use /etc/codex/managed_config.toml. Codex still reads it on macOS and Linux, but requirements.toml is the current file for enforced settings, and Windows no longer reads managed_config.toml.

​
Set up with the CLI

You can also register the Codex log source with the Sazabi CLI (installed and authenticated — see CLI reference). Registering the source mints the same intake URL the dashboard shows above (the public key is embedded in its hostname):
The command prints the intake URL for the new source — copy the whole URL and point your sender at it using the configuration shown above. Run sazabi log-sources get <log-source-id> at any time to reprint the endpoint, or sazabi log-sources list to see every log source in the project.

​
Verify

Start a Codex session and run a prompt. Open the Intake page in the Sazabi dashboard and confirm events from the Codex source appear within a minute or two. Each event’s originator attribute names the Codex client that ran the session — for example codex_cli_rs for the CLI or codex_vscode for the IDE extension — so you can confirm desktop app and IDE extension sessions are arriving alongside CLI sessions. Start a thread and search for codex.api_request to find model API requests, or search for conversation.id to view all events from a single conversation.

​
Troubleshooting

No events after restarting — Confirm ~/.codex/config.toml is valid TOML with a single [otel] table that carries both log_user_prompt and exporter. Check for a duplicated [otel] header and for syntax errors such as mismatched quotes or missing brackets. Desktop app or IDE extension sends nothing — Both read ~/.codex/config.toml only when they start. Fully quit and reopen the desktop app, or restart your editor, after editing the file. A [otel] section in a project’s .codex/config.toml has no effect. Managed rollout has no effect — Confirm the file is at the path for that operating system and parses as TOML; Codex rejects unknown keys in the [otel] table. Restart the Codex client after changing it. Events appear but prompts are missing — log_user_prompt must be true for prompt text to be included. Setting it to false keeps prompt text out, but session structure, API metadata, and tool-call content — every tool’s inputs and results, not only shell commands — are still exported. Endpoint URL format — Codex requires the full endpoint URL including /v1/logs. If you omit the path suffix, Codex will not append it automatically and events will not reach the correct intake path. Codex metrics are not stored — Only OTLP log events are ingested. Metric events from Codex are not stored by this source.

​
Further reading

Intake

See per-source ingestion volume and health.

Log sources

Browse the full log source catalog.