analytics.enabled
true (per config-advanced; config-reference lists no default)Published Jul 15, 2026 · Verified against the official config docs
Collects anonymous usage and health data and ships it to OpenAI. It's a boolean under an `[analytics]` table, and `analytics.enabled = false` turns it off in one line. Watch the default: the config-advanced page says it's on (`true`) out of the box, while the config-reference table leaves the default blank and says the client default applies when unset.
Codex phones home by default. The config-advanced page puts it plainly: “By default, Codex periodically sends a small amount of anonymous usage and health data back to OpenAI.” That data is meant to catch malfunctions and show which features get used, and the same page says the metrics exclude PII. If you’d rather send nothing, this is the one key that closes the tap.
Values
| Key | Type | Values | Default |
|---|---|---|---|
analytics.enabled |
boolean | true / false |
see below |
Here’s the wrinkle worth knowing up front. The config-advanced page says analytics is true (enabled) out of the box. The config-reference table leaves the default column blank and describes it as “Enable or disable analytics for this machine/profile. When unset, the client default applies.” Two official pages, two different stories on what happens when you don’t set it. Set it explicitly and the ambiguity goes away.
# ~/.codex/config.toml
[analytics]
enabled = falseWhen to change it
- You want telemetry off. Set
enabled = false. This is a common enough ask that “codex disable telemetry” is one of the phrases people type straight into search. One line does it. - Company policy on data egress. If your shop bars background reporting to outside vendors, flip this to false in the machine-level config so every project inherits it.
- You’re fine helping OpenAI catch bugs. Leave it alone (or set
trueto be explicit) and the health data keeps flowing.
Gotchas
The default discrepancy above is the real one. Don’t assume “unset” means off. The config-advanced page says the opposite, so treat unset as on until you’ve confirmed otherwise on your build.
analytics.enabled is a separate pipe from OpenTelemetry. The otel.* keys run their own system: otel.metrics_exporter defaults to statsig, while otel.exporter and otel.trace_exporter default to none. Turning analytics off does not touch whatever otel exporter you’ve configured, and turning otel on doesn’t re-enable analytics. If you wire up your own OTel backend and care about prompt contents, otel.log_user_prompt is the redaction switch: it defaults to false, so raw prompts stay out of the logs until you opt in.
Related settings
profiles: the reference describes analytics as being set “for this machine/profile,” so you can scope it per profile the same way you scope model or approval settings.