Operate Codex in production

Operating Codex after rollout means watching four signals: usage against plan allowances (/status, /usage and OpenTelemetry from the [otel] config table), install health (codex doctor), the performance of the code Codex ships, and the security of that code. Each signal has an owner and a page, so nobody has to watch sessions.

This hub is for developers and tech leads who own Codex for a team after the first month. The weekly allowance runs out on Wednesday, one teammate’s sessions behave differently from everyone else’s, and a security reviewer asks what the agent changed last week. CLI commands on this page were checked against Codex CLI 0.157.1 on 2026-09-26.

Which Codex operate page answers your question?

Your question	Page
Where do credits and allowances go, and how do I make them last?	Codex credits, usage limits and cost optimization
How do I find and fix a slow endpoint or query with Codex?	Performance optimization with Codex
How do I audit a codebase for vulnerabilities with Codex?	Security scanning with Codex
How do Codex Security findings reach a tested, merged fix?	Codex Security and the agents command center

Telemetry that covers every agent lives in observing the agents. Spend policy across vendors lives in cost governance, and model prices live on the models hub.

How do you set an operating baseline for Codex?

Do this once per team, before you tune anything.

1. Check every install. In a terminal, run codex --version and codex doctor --summary. codex doctor checks the installation, config, auth, connectivity and runtime health; --json emits a redacted report you can attach to a support ticket or collect from each machine. Record the version, because defaults change between releases.

2. Read your own usage. In a session, /status shows estimated thread credits or cost for eligible workspaces (since CLI 0.148.0), and /usage shows account usage and offers a usage-limit reset (since 0.156.0). Allowances run on five-hour and weekly windows.

3. Export telemetry to your collector, not only to OpenAI. Add an [otel] table to the user config (~/.codex/config.toml) or the system config (/etc/codex/config.toml):

   [otel]
   environment = "prod"
   log_user_prompt = false          # the default; prompts stay out of the export
   
   [otel.exporter.otlp-http]
   endpoint = "http://localhost:4318/v1/logs"
   protocol = "binary"

   Codex ignores otel in a repository’s .codex/config.toml (project-local deny list, 0.157.1), so a cloned repository cannot redirect it. The exporter defaults to none. The full event list and alert rules are in advanced Codex setups.

4. Bound every unattended run. codex exec has no spend-cap flag in 0.157.1 (checked with codex exec --help on 2026-09-26). Bound CI runs with the job timeout, one task per run, and --ephemeral so sessions are not persisted. In GitHub Actions, set timeout-minutes: 20 on the job that runs codex exec --ephemeral.

5. Keep one model policy. GPT-6.1 Sol is the bundled default since CLI 0.159.1 and runs at low effort by default. Raise model_reasoning_effort before you switch model, and move routine jobs to GPT-6 Luna only when your own evals say the result holds. Prices are on the models hub.

Copy-paste prompt: audit this repository's Codex setup for cost and risk

Do not edit any files. Audit how Codex is configured for this repository:
AGENTS.md (root and nested), .codex/config.toml, .codex/ skills and hooks,
and any codex exec calls in .github/workflows/ or scripts/.
Report a table with columns: file, finding, cost or risk, fix. Look for:
1. AGENTS.md content over 200 lines, or rules repeated across files (loaded every session).
2. MCP servers that nothing in the repository or the last 20 commits refers to.
3. Unattended runs using --dangerously-bypass-approvals-and-sandbox or danger-full-access.
4. CI jobs that call codex exec without a timeout.
End with the three changes that save the most usage and the one that removes the most risk.

Copy-paste prompt: turn a month of Codex telemetry into an operating review

Read ops/codex-events.csv, exported from our OpenTelemetry collector
(one row per Codex event with user, model, date and event name).
First print the column names you found; if user, model, date or event name is missing,
stop and say so. Do not guess missing values. Report:
1. Sessions per active developer per week, as median and 90th percentile.
2. The share of sessions per model and per reasoning effort.
3. Every denied tool decision or sandbox outcome in an unattended run, grouped by job.
4. Any week where sessions rose more than 30% with no matching rise in merged pull requests.
Write the result to ops/codex-review.md, cite the rows behind every number,
and list the rows you could not parse.

How do you know Codex is operating well without watching sessions?

Read owned signals, not transcripts. Open a session only when a signal points at it.

Signal	Where it comes from	What healthy looks like	Owner
Usage	/status, /usage, and your OpenTelemetry collector	Nobody hits the weekly window before the week ends; every developer shows up in the collector	Tech lead
Install health	codex doctor --json after each upgrade	No failed checks; one CLI version across the team	Each developer
Performance of shipped code	Your application’s traces and benchmarks	No regression after a Codex change; see performance optimization	On-call engineer
Security of shipped code	@codex security review (GitHub trigger verified 2026-08-28), your scanners, and an exploit test per fix	Every high finding has a failing-then-passing test or a documented dismissal	Code owner

The stage before this one is review and ship with Codex. Team-wide policy, requirements.toml and audit evidence are in Codex enterprise governance.

What breaks when Codex runs every day?

Symptom	Cause	Recovery
The weekly allowance runs out mid-week	Broad exploratory tasks, a long AGENTS.md, or effort raised for every task	Check /status per thread, split tasks, trim AGENTS.md, and set effort per job; see cost optimization
The collector shows nothing from one developer	An [otel] table in /etc/codex/config.toml is only a default: the developer’s ~/.codex/config.toml overrides it. Or no exporter was ever set.	Compare the developer’s ~/.codex/config.toml [otel] table with /etc/codex/config.toml; run codex doctor only to catch startup warnings such as ignored project-local keys; reconcile collector coverage against seats monthly
One teammate gets a different model or behaviour	Different CLI versions: GPT-6.1 Sol is the default only from 0.159.1 (GPT-6 Astra from 0.153.4 until then)	Compare codex --version; run codex update
A CI job runs far longer than planned	codex exec has no spend cap in 0.157.1	Add a job timeout and fail the job when it trips; keep one task per run
A vulnerability ships in a Codex-written change	Security review ran only when someone remembered	Make @codex security review and an exploit test a merge gate; see Codex Security

When an agent run causes a production incident, follow agent incident response: revoke its credentials first, then investigate.

Where to go next with operating Codex

Make the allowance last

Codex credits, usage limits and cost optimization

Observe the agents

Agent telemetry

Set team policy

Codex enterprise governance

Across all tools

DevOps with AI

For other agents, see operate Claude Code and operate Cursor.