> ## Documentation Index
> Fetch the complete documentation index at: https://docs.sazabi.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Codex

> Add an [otel] section to your Codex config to ship session telemetry — prompts, tool calls, and model API requests — to Sazabi via Codex's built-in OTLP exporter.

[All Codex integration capabilities](https://docs.sazabi.com/catalogs/integrations/codex.md)

## About

Ship Codex session telemetry to Sazabi using Codex's built-in OTLP exporter. The Codex CLI, the [Codex desktop app](https://developers.openai.com/codex/app), and the [Codex IDE extension](https://developers.openai.com/codex/ide) 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).

> [!WARNING]
>
> 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.

> [!WARNING]
>
> 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

**Step 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.

```toml title="~/.codex/config.toml" theme={"system"}
[otel]
log_user_prompt = true
exporter = { otlp-http = { endpoint = "<your intake URL>/v1/logs", protocol = "binary" } }
```

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.

**Step 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`](https://developers.openai.com/codex/enterprise/managed-configuration). 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.

```toml title="requirements.toml" theme={"system"}
[otel]
log_user_prompt = false
exporter = { otlp-http = { endpoint = "<your intake URL>/v1/logs", protocol = "binary" } }
```

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](https://docs.sazabi.com/reference/cli.md) (installed and authenticated — see [CLI reference](https://docs.sazabi.com/reference/cli/log-sources.md)).

Registering the source mints the same intake URL the dashboard shows above (the public key is embedded in its hostname):

```bash theme={"system"}
sazabi log-sources create codex --mode manual
```

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](https://docs.sazabi.com/guides/instrument/intake.md) 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

> [card] [Intake](https://docs.sazabi.com/guides/instrument/intake.md)
>
> See per-source ingestion volume and health.

> [card] [Log sources](https://docs.sazabi.com/catalogs/log-sources.md)
>
> Browse the full log source catalog.


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.