This appendix is the Codex-specific counterpart to Appendix B. Same scoping discipline: convergent primitives (briefing doc, slash commands, headless mode) live in the body chapters; this reference covers what’s different and when Codex is the better fit.

What Codex CLI is

Codex CLI is OpenAI’s open-source command-line agent. Like Claude and Gemini, it runs an agent loop against a model backend, exposes tool-calling, and supports both interactive and headless modes. Its characteristic design choice is the approval mode model for permissions — a tighter, more declarative alternative to the allow/deny list patterns the other tools use.

Key defaults at time of capture:

SurfaceCodex CLI
Binarycodex
Interactive entrycodex
Non-interactiveApproval-mode flags; see below
Briefing docAGENTS.md at repo root
BackendOpenAI API or Azure OpenAI; configurable via env
SandboxBuilt-in filesystem / command sandbox

Approval modes: the distinctive permission surface

The approval-mode levels, at time of capture, span roughly:

For automated pipelines the approval-mode flag is the primary configuration. The discipline from Ch 12 applies: pick the most restrictive mode that still lets the workflow complete, not the most permissive one that always works.

The built-in sandbox

Codex ships a filesystem and command sandbox as a first-class feature rather than as an optional hook. File writes default to a scoped working directory; shell commands run inside a constrained environment; network egress can be restricted per invocation.

This changes the default risk posture. Where Claude and Gemini rely more heavily on hook-based or permission-based guardrails that the operator configures, Codex ships stricter defaults and lets the operator loosen them. For CI integration and scheduled runs the sandbox is a meaningful safety net — misconfiguration errs toward blocking rather than toward blast radius.

Backend flexibility

Codex’s backend is configurable via environment variables, which makes it particularly easy to point at alternative inference endpoints: the default OpenAI API, Azure OpenAI (enterprise default), or any OpenAI-compatible proxy (including private inference servers hosting compatible model gateways). The environment-variable approach is less opinionated than either Claude’s Bedrock/Vertex integrations or Gemini’s Vertex-native path, which makes Codex particularly flexible for unusual deployment topologies.

For enterprise deployment (Ch 14), this manifests as an easier path to self-hosted or proxied inference. For teams using Azure as their cloud, the integration is natively ergonomic.

What’s thinner

Being honest about the comparison: some of the surface that is mature in Claude (and reasonably mature in Gemini) is thinner or differently-shaped in Codex.

These gaps are narrowing over time — the convergence axis of Ch 15 applies — but as of the last-verified date, a team leaning heavily on any of them will find more ergonomic surfaces in Claude.

Authentication

Codex authenticates via API key or via Azure OpenAI’s credential chain. Key management in enterprise deployments typically routes through a secrets store (HashiCorp Vault, AWS Secrets Manager, Azure Key Vault); the CLI reads the key from an environment variable that the secrets infrastructure populates.

For interactive personal use, the pattern is the OpenAI API key in ~/.config/codex/config.toml or equivalent. Keep the key out of committed files; the same discipline applies to Gemini and Claude secrets.

When Codex CLI is the right fit

Situations where Codex is a particularly strong choice:

Situations where another tool may fit better:

Quick reference