Codex: Advanced

Advanced

At this level Codex is part of your daily work. The wins now come from configuration, connecting it to your tools, and making verification automatic rather than manual.

Configure it: config.toml

Codex reads a config.toml from $CODEX_HOME (default ~/.codex). A project can add its own .codex/config.toml, but it only loads in projects you’ve marked trusted. That trust gate is deliberate: an untrusted repo’s config and agents are silently skipped, so a checked-out stranger’s project can’t reconfigure your agent.

A minimal ~/.codex/config.toml that covers the essentials of this page:

# Auto-compact before context degrades (tune to ~60% of your effective window)
model_auto_compact_token_limit = 155000

# Trust decisions live here, per project path
[projects."/Users/you/work/my-project"]
trust_level = "trusted"

# An MCP server Codex can call as a tool
[mcp_servers.issues]
command = "npx"
args = ["-y", "mcp-linear"]
env = { LINEAR_API_KEY = "..." }

Team Config (since 2026-01-23) layers shared settings, rules/, and skills/ across three scopes (system /etc/codex/, user ~/.codex/, project .codex/), with admins able to enforce a baseline via requirements.toml.

Caution

Project-scoped .codex/ config, subagents, and MCP servers load only for trusted projects. If something defined in a repo isn’t taking effect, check the project’s trust level first.

The key worth setting early is model_auto_compact_token_limit: it controls when Codex auto-compacts a long session. Community guidance puts it around 60% of your effective window, so compaction fires before context starts to degrade rather than after.

Tune autonomy from the command line

The beginner approval modes map to two CLI flags you set per run:

Flag	Values
--sandbox	read-only · workspace-write · danger-full-access
--ask-for-approval	untrusted · on-request · never

For normal work, --sandbox workspace-write with --ask-for-approval on-request is the sane default. --add-dir <path> grants an extra writable directory (repeatable). --yolo (alias --dangerously-bypass-approvals-and-sandbox) turns off both gates; keep it for disposable containers only, never on a dev machine with secrets.

Connect your tools with MCP

Codex is an MCP client. Add a server under [mcp_servers.<id>] in your config.toml (like the issues server in the snippet above) and Codex can call it as a tool: a database, an issue tracker, an internal API. Project-scoped servers live in .codex/config.toml and, again, load only in trusted projects.

Three more extension points sit alongside MCP:

• Skills: reusable SKILL.md instruction and workflow bundles (the successor to the deprecated custom prompts).
• Plugins: installable bundles packaging skills, MCP config, and app integrations, with a marketplace.
• Hooks (GA 2026-05-14): run your own logic on lifecycle events, for example a check before a command runs.

This is context engineering at the tool layer: you decide what Codex can reach.

Make code review automatic

Verification is where Codex earns trust. Two layers:

• Local: /review runs a separate reviewer agent over your diff without touching the working tree. Because tests and builds run inside the sandbox, the reviewer reads real pass/fail evidence, not guesses.
• On GitHub: comment @codex review on a PR and Codex posts a standard GitHub review; turn on Automatic reviews to check every new PR. It’s tuned for high-signal issues and checks whether the changes match the PR’s stated intent, flagging regressions, missing tests, and doc gaps. @codex fix ... turns a finding into a change.

Add a ## Review guidelines section to AGENTS.md to steer what the reviewer cares about. The human still reads the diff before merge; the point is verification on evidence, not assertion.

Start automating

For long, well-defined jobs use Goal mode (/goal, GA 2026-05-21 in the CLI, IDE, and app): state one objective and Codex self-plans, executes, runs tests, and course-corrects for as long as it takes, logging test results as evidence. The catch: it can’t infer “done” from a vague spec. Give it a sharp, testable target (“migrate Pydantic v1 to v2, all tests green”) or it will loop.

For scripted, non-interactive runs, codex exec is the headless entry point, and the foundation of the Expert track.

You’re done when…

• ✅ You have a config.toml and know your projects’ trust levels
• ✅ At least one MCP server or Skill is wired in
• ✅ /review or @codex review runs on your changes as a habit

Next step

Ready to orchestrate many sessions at once: subagents, parallel cloud tasks, and Codex wired into CI?

Codex: Expert Subagents, parallel cloud tasks, headless scripting, and CI, without leaking secrets.