Tool map: Claude Code, Cursor, and Codex

The tool map shows which Claude Code, Codex, and Cursor feature implements each stage of the AI-native lifecycle. The artifacts, the human gates, and the CI checks stay in Git and are identical across tools; only the harness surface changes. The Claude Code and Codex commands were checked against the installed CLIs on 26 September 2026.

This page is for the developer who runs one lifecycle stage in a tool the stage page does not show first, and for the tech lead whose team uses all three. The situation it fixes: half the team plans in Cursor, a script in CI calls Codex, and a teammate pastes a Claude Code flag into the Codex command line. The run fails, or worse, it runs with a weaker control than the stage page intended.

What the tool map gives you

• One table that names the feature for each lifecycle stage in each tool, with the version it was checked against.
• The portable layer: which files carry the lifecycle between tools, and how to keep one instruction file for all three.
• Side-by-side commands for plan, isolate, verify headless, and review, in <Tabs>.
• A flag-check script that fails CI when a tool update removes a flag your automation depends on.
• Two copy-paste prompts: a portability audit and a flag audit.
• The recovery for each way a cross-tool setup usually breaks.

Which feature implements each lifecycle stage?

Read a row as “to run this stage, use this feature”. The stage pages hold the procedure; this table only tells you where the procedure lives in your tool. Claude Code rows were checked on version 2.1.283 and Codex rows on 0.157.1, both on 2026-09-26. Cursor rows were checked on Cursor’s documentation on 2026-08-28; cursor.com could not be reached on 2026-09-26, so re-check a Cursor row before you automate against it.

Stage and play	Claude Code 2.1.283	Codex 0.157.1	Cursor (docs, 2026-08-28)
Plan: capture intent.md	Interactive session; commit the accepted file	Interactive session; commit the accepted file	Agent chat; commit the accepted file
Design: write spec.md	Skills in .claude/skills/; context in CLAUDE.md	Skills in .agents/skills/; context in AGENTS.md	Agent Skills and Rules
Build: plan before code	--permission-mode plan, /plan, or Shift+Tab	/plan in the terminal UI	Plan Mode
Build: parallel isolation	-w, --worktree [name]	--worktree flag or /worktree	Worktrees
Test: session feedback loop	Check command in CLAUDE.md; hooks in .claude/settings.json	Check command in AGENTS.md; hooks (need persisted trust)	Check command in Rules; Hooks
Test: deterministic controls	Permission modes, sandboxed Bash, hooks	Sandbox or permission profile (beta), approval policy, hooks	Hooks, Run modes
Deploy: headless run	claude -p with --output-format json	codex exec with --json or --output-schema	CLI print mode (-p, --print)
Deploy: pull-request review	/code-review locally; anthropics/claude-code-action@v1; managed Code Review (research preview, Team and Enterprise)	codex review; @codex review on GitHub; openai/codex-action@v1	Bugbot on the pull request
Maintain: background and scheduled work	--bg sessions; Routines (/schedule, research preview); CI schedules	Automations and scheduled tasks; codex cloud (experimental); CI schedules	Cloud Agents; Automations (schedule, Slack, Linear, webhook, and others)
Production authority	Outside the agent: release gate and credentials the session cannot read	Same	Same

The last row is the same in every column on purpose. No tool setting replaces a release gate the model cannot reach; the deploy stage shows where to put it.

A shared name is not a shared control

Rules and skills steer the agent. Hooks, sandboxes, and approval policies can block an action. A Git worktree isolates files, not the database, cloud account, secrets, or third-party APIs behind them. Before you treat two features as equivalent, check which of these they are; permissions and sandboxes across the three tools compares the enforcement side row by row.

Keep the lifecycle in files every tool reads

The lifecycle survives a tool switch only if its state lives in the repository. Four kinds of file do the carrying:

• Artifacts. intent.md, spec.md, plan.md, and REVIEW.md are plain Markdown; the artifact chain has a template for each. Any tool reads them.
• The instruction file. Codex reads AGENTS.md. Claude Code reads CLAUDE.md, and from v2.1.277 it also reads AGENTS.md when a project has no CLAUDE.md; that behaviour is on the latest release channel only (the stable channel was on 2.1.274 on 2026-09-26). To serve both channels, keep the content in AGENTS.md and put a one-line CLAUDE.md that imports it with @AGENTS.md. For Cursor, put the same check command in a Rule; whether Cursor reads AGENTS.md could not be re-verified for this page.
• Skills. A skill is a folder with a SKILL.md file, an open standard that all three tools implement. Commit it once and copy or link it into .claude/skills/ for Claude Code and .agents/skills/ for Codex; the skills CLI (1.7.0 source, checked 2026-09-26) also installs Cursor’s project skills into .agents/skills/, so one copy there serves both; agent skills covers packaging.
• The check command. One command, such as npm run typecheck && npm run lint && npm test, named in the instruction file and run again in CI. The CI run is the one that counts, because the agent cannot edit it.

Hooks do not port. Claude Code hooks live in .claude/settings.json, Codex hooks need persisted trust before they run, and Cursor hooks speak JSON over stdio. Keep the logic in a script under version control and give each tool a thin hook entry that calls it; hooks as deterministic guardrails shows the pattern.

How do the commands differ between Claude Code, Codex, and Cursor?

The four jobs below are where the tools differ most in syntax. Each tab does the same job.

Claude Code

# Terminal. Plan first, in an isolated worktree.
claude --permission-mode plan -w payments-retry

# CI or a script. Read-only review with structured output.
claude -p --output-format json \
  --allowedTools "Read,Grep,Glob,Bash(git diff *)" \
  "Review the diff against main using REVIEW.md. Report Important findings only."

claude -p starts in Manual permission mode even where interactive sessions start in auto mode, so name the tools the run may use. In a session, /code-review reviews the local diff.

Codex

# Terminal. Isolated worktree, then type /plan before the agent starts.
codex --worktree

# CI or a script. Non-interactive review of the changes against main.
codex review --base main

# CI or a script. Run the checks with the :workspace permission profile, JSONL events on stdout.
codex exec -c default_permissions=":workspace" --json \
  "Run npm run typecheck && npm run lint && npm test and fix only what fails."

The example uses a permission profile (beta), which OpenAI now prefers over the legacy --sandbox workspace-write. If you need the stable, non-beta control, use --sandbox instead, but never both: OpenAI says the two systems do not compose. codex exec has no -a flag in 0.157.1 and needs none: it already runs with approval: never, and a codex -a … exec prefix does not change that.

Cursor

Switch the agent to Plan Mode before you describe the change, and run parallel attempts in Worktrees. For headless runs, Cursor’s CLI has a print mode (-p, --print) and a documented GitHub Actions setup. This page does not pin the CLI binary name: it could not be re-verified on 2026-09-26, so copy it from Cursor’s headless CLI docs. Bugbot reviews the pull request on the Git host.

How do you know the tool map still holds?

Claude Code releases roughly once a day on its latest channel. Nobody should re-read three changelogs to find out whether a flag moved. Two checks do it instead.

1. Fail CI when a flag disappears. Commit this script and run it in the job that installs the agent CLIs, before any job that calls them. It greps the installed --help output for every flag your automation uses.

   #!/usr/bin/env bash
   # scripts/check-agent-flags.sh — fails when an installed CLI drops a flag we depend on.
   set -uo pipefail
   status=0
   need() { # need "<command words>" "<flag>"
     if ! $1 --help 2>&1 | grep -qE -- "^\s+(-[a-zA-Z], )?$2\b"; then
       echo "missing: $1 $2" >&2
       status=1
     fi
   }
   need "claude" "--permission-mode"
   need "claude" "--worktree"
   need "claude" "--output-format"
   need "codex" "--worktree"
   need "codex exec" "--json"
   need "codex exec" "--output-schema"
   need "codex review" "--base"
   exit $status

   Add a need line whenever a script or workflow starts using a new flag. A red run names the missing flag, which is the whole diagnosis.

2. Run the same gate whatever tool produced the change. The CI check command and the review agent do not care which harness wrote the diff. If a change made in Cursor passes a gate that a change made in Codex fails, the gate is fine and one tool’s instruction file has drifted; the portability audit below finds where.

The tech lead owns the map for the team: the flag script, the shared instruction file, and the date on this table when you copy it into your own docs.

Copy-paste prompt: portability audit

Audit this repository for lifecycle state that only one agent tool can see.
Do not edit anything. Read AGENTS.md, CLAUDE.md, .claude/, .agents/, .codex/,
.cursor/ and every CI workflow under .github/workflows/.
Report a table with columns: file, tool that reads it, lifecycle stage it
serves (plan, design, build, test, deploy, maintain), and whether an
equivalent exists for Claude Code, Codex and Cursor.
Then list: (1) instructions that differ between tool-specific files,
quoting both versions; (2) check commands named in one instruction file
but not in CI; (3) hooks whose logic is inline rather than in a committed
script. End with the three moves that would make one file the source of truth.

Copy-paste prompt: flag audit against the installed CLIs

Find every place this repository invokes claude, codex or a Cursor CLI:
scripts/, Makefile, package.json scripts, and .github/workflows/.
For each invocation, run the same binary's --help (and the subcommand's
--help) and check that every flag and value used appears there.
Do not run the invocations themselves and do not edit files.
Report: file and line, the command, the flag, found or missing, and the
installed version from --version. For each missing flag, propose the
replacement shown in --help and say whether it changes the permissions
the run gets.

What breaks when you map a lifecycle across tools?

A copied flag fails or means something else. Typical cases on 2026-09-26: --full-auto is absent from codex --help and codex exec --help 0.157.1; codex -a accepts only on-request and never; codex exec -a never fails with “unexpected argument”, because codex exec has no -a and already runs with approval: never. Recovery: run the flag audit prompt, fix the call, and add the flag to scripts/check-agent-flags.sh so the next removal fails CI instead of production.

Claude Code ignores AGENTS.md on one machine. That machine is on the stable channel, older than v2.1.277, or has the toggle off under “Project instructions” in /config. Recovery: add the one-line CLAUDE.md with @AGENTS.md, which works on every channel.

One tool has no equivalent control. Cursor’s Run modes, Codex’s approval policy, and Claude Code’s permission modes do not line up one to one. Recovery: move the control out of the tool into Git, CI, identity, or the deployment platform, where every tool is subject to it. Never rename an instruction in a prompt and present it as enforcement.

A tool-specific record becomes the only source of truth. A plan accepted in a chat window, a Codex cloud task, or a Cursor Cloud Agent run leaves the repository without the decision. Recovery: commit the accepted result as plan.md or link the external record and the commit SHA from the pull request; the artifact chain names one source of truth per artifact.

Hooks run in one tool and silently not in another. Codex skips a hook until its trust is persisted, and a Claude Code hook in .claude/settings.json means nothing to Cursor. Recovery: keep the check in CI as well, so the hook is a fast early warning and never the only gate. Do not pass --dangerously-bypass-hook-trust to make the warning go away; it is meant for automation that already vets hook sources.

The worktree is isolated but the side effects are not. Two agents in two worktrees still share the local database, the ports, and any cloud credentials in the environment. Recovery: give each worktree its own ports and data, as Git worktrees for parallel agents describes, and keep production credentials out of every agent session.

Where to go next from the tool map

• Prerequisite: the artifact chain, which defines the files this map keeps portable.
• Next: pick the stage you run this week, starting with Build, and measure the loop with SDLC metrics.
• Enforcement side by side: permissions, sandboxes, and approval modes.
• Model choice per tool, with current names and prices: the models hub.

Claude Code Plan mode, CLAUDE.md, skills, hooks, worktrees, subagents, and headless runs.

Codex Plan mode, AGENTS.md, skills, worktrees, sandboxing, review, and automations.

Cursor Plan Mode, Rules, Agent Skills, Worktrees, Bugbot, Cloud Agents, and Automations.