Codex 2026:
the practical map.

If you have read the Codex map before, start here. This is the dated layer for guide changes and recently verified product boundaries.

Codex work can happen locally, in the app, in the cloud, in an IDE, or from your phone. The first practical skill is picking the right surface before the task starts.

Codex's repo memory primitive is AGENTS.md. Treat it like code: short, local, versioned, and specific enough to prevent mistakes.

Inspect the AGENTS.md instructions that apply to this directory before changing code.

Report:
- which files you read
- which instructions affect this task
- which lines are stale, duplicated, contradictory, or too broad
- one small cleanup that would prevent a real mistake

Do not edit yet. Keep the recommendation under 10 bullets.

Codex uses the same broad idea as Claude Code: progressive disclosure for procedures, deterministic hooks for guarantees, and plugins for packaging repeated capability.

I keep repeating this process:
<paste the steps or prompt>

Turn it into a Codex skill design.

Return:
- trigger phrases
- a short SKILL.md outline
- what belongs in reference files instead of AGENTS.md
- one verification step
- one case where this should stay a normal prompt

Do not propose a plugin unless this process needs to travel across repos or teammates.

Codex subagents are configurable workers. The app adds the practical surface for parallel threads, worktrees, and cloud/local mode selection.

Explorer task:
Map the files, commands, and risks for this change. Do not edit. Return exact paths, likely tests, and unknowns.

Worker task:
Use the explorer notes only as input. Implement the smallest safe diff for:
<task>

Rules:
- stay inside <allowed paths>
- ask before touching shared contracts
- done means tests/checks run and changed files listed

Codex automations are recurring background tasks. The useful version is not "let it do everything"; it is "wake up, inspect, produce a useful artifact, and stop."

Every weekday morning, inspect the project and produce a triage note.

Scope:
- read issues, failing checks, recent commits, and TODOs
- do not edit files
- do not run migrations, deploys, dependency updates, or external writes

Output:
- top 5 items by urgency
- evidence for each item
- suggested owner/action
- anything that needs human approval

MCP gives Codex access to tools and data beyond the repo. Treat every integration as a capability with a blast radius, not a novelty to collect.

Before adding MCP for this task, decide if it is worth it.

Need:
<what live data or action the agent needs>

Return:
- whether repo files or public docs are enough
- the minimum MCP server and permissions needed
- whether read-only access is sufficient
- what the agent must never do through this tool
- how we will verify the result without trusting the tool blindly

Practitioner writeups that hold up converge on a boring loop: plan, persist truth, scope one ticket, execute, verify, report, update durable docs.

Work on exactly this ticket:
<paste ticket>

Before editing:
- inspect the relevant files
- name the smallest safe diff
- list any paths you will not touch

Rules:
- do not edit outside <allowed paths>
- keep behavior changes explicit
- preserve unrelated work

Done means:
- changed files listed
- tests/checks run with results
- manual verification noted if relevant
- proof attached when UI, mobile, data, or external behavior changed
- remaining risks named plainly

The strongest process is a conductor pattern: one deep context holder owns the project truth, while Claude Code and Codex do bounded work in separate lanes. Use them to create independent evidence, not more tabs to babysit.

You are competing against <competitor name>. Build the best solution to this exact task.

Task:
<paste the task>

Acceptance criteria:
<paste the checklist>

Rules:
- Same repo, same constraints, no shortcuts.
- Optimize for correctness, smallest safe diff, clear product fit, and verification evidence.
- Do not imitate the competitor. Beat them by being more precise.
- Done means: changed files listed, tests/checks run, risks named, and any manual verification described.

Review this work as if <competitor name> already approved it and your job is to find what they missed.

Focus on:
- correctness and hidden edge cases
- security, data loss, privacy, and permission mistakes
- missing tests or weak verification
- unnecessary scope creep
- mobile/browser/product regressions

Give file/line evidence. Rank findings by severity. If there are no real issues, say that clearly and name the residual risk.

Compare Solution A and Solution B. Pick the winner or merge the best parts.

Judge by:
- correctness
- maintainability
- smallest safe diff
- test and browser evidence
- product fit
- risk of hidden follow-up work

Do not compromise by averaging. Make a decision, explain it, and give the next concrete action.

• "Codex mobile is cloud execution." No. Mobile access depends on a connected host for local resources.
• "Automations mean laptop-off workers." Sometimes cloud tasks can run away from your machine, but app/project automations may require the host and project available. Check the specific mode.
• "Recursive subagents are better." Deeper fan-out increases cost, latency, and predictability risk. Start at depth 1.
• "AGENTS.md can hold the whole manual." It has a documented byte budget and the same practical bloat problem as CLAUDE.md.
• "Codex should freestyle the app." Strong runs scope tickets, persist truth, verify, and report. Freeform autonomy mostly creates review debt.
• "A passing check is the same as proof." No. Tests prove what they cover. UI, mobile, permissions, data, and external integrations usually need one more direct inspection step.

This mirrors the Claude Code checklist style. The next step is making these interactive in the Dojo.

Primary sources first. Reviews and community writeups are included only as practitioner signal.