# Codex vs Cursor and Claude Code: strengths and trade-offs

URL: https://developertoolkit.ai/en/comparison/vs-codex/
Description: Where OpenAI Codex's multi-surface model beats Cursor and Claude Code, where it costs you, and one verification gate all three must pass.

OpenAI Codex is a coding agent reachable from a CLI, an IDE extension, a desktop app, cloud tasks, `@codex review` on GitHub and GitLab, `@Codex` in Linear and `@ChatGPT` in Slack, all under one account and one `AGENTS.md`. That reach is its edge over Cursor and Claude Code. Its cost is more surfaces to govern, and all three tools face the same verification gate.

Your product manager posts in Slack: "The auth tests are failing on main, can someone fix it before the release?" You can open your editor, find the failure and fix it. Or someone replies `@ChatGPT fix the failing auth tests` and, with Cloud delegation enabled, a Codex cloud task starts while you finish what you were doing. This page is for developers deciding where Codex fits next to Cursor or Claude Code, and for tech leads and CTOs who must make a third agent produce work of the same, provable quality.

## What does this Codex comparison cover?

- A surface-by-surface map of Codex, Cursor and Claude Code, with every fact dated.
- A decision table that sends each kind of task to the tool that fits it.
- Five copy-paste prompts: the same delegated task in each tool, a pull request review, and a cross-agent review.
- A verification gate for Codex: review, structured evidence and CI.
- The failure modes of adding Codex to a team, with a recovery for each.

## How is Codex different from Cursor and Claude Code?

All three are coding agents. Each reads the repository, plans, edits files, runs commands and iterates until its checks pass. The [tool comparison overview](/en/comparison/) explains that shared loop. They differ in where the loop runs and where you supervise it.

| | Codex | Cursor | Claude Code |
| --- | --- | --- | --- |
| Home surface | No single home: CLI (`codex`), IDE extension, desktop app, cloud tasks | A VS Code-based editor with Tab completions, inline edit and an Agent panel, plus an Agents Window | The terminal (`claude`), plus a desktop app, IDE extensions and a web version |
| Start work from a chat or tracker | `@ChatGPT` in Slack (with Cloud delegation, repository work goes to a Codex Cloud task) and `@Codex` in Linear; Codex cloud tasks you continue from the web, mobile or desktop app; `@codex review` on GitHub and, in beta, on GitLab | Automations triggered from Slack, Linear, source control, webhooks and schedules; `@Cursor` in Linear comments starts a Cloud Agent | Claude Tag (Public Beta; Team, Enterprise) or the earlier Slack app (Pro, Max; retired 2026-10-05 in workspaces paired with a Claude organization); GitHub via `anthropics/claude-code-action@v1` |
| Remote execution | Codex cloud: `codex cloud exec` (experimental in CLI 0.157.1–0.162.1), then `codex cloud apply` to pull the diff locally | Cloud Agents in isolated VMs | Web sessions, background sessions (`claude --bg`), Routines (research preview) |
| Pull request review | `@codex review` on GitHub and, in beta, GitLab; `@codex security review` (research preview) on GitHub; `codex review` locally | Bugbot | `/code-review` in a session; managed Code Review (Team and Enterprise; generally available per Anthropic, checked 2026-10-16) |
| Parallel isolation | `--worktree` / `/worktree`: worktree support on since 0.156.0; a session uses one only when you pass `--worktree` or run `/worktree`; 0.162.0 added managed Git worktree tools (create and list worktrees from trusted projects) | Worktrees | `--worktree` (`-w`) |
| Hooks | 12 events; a hook runs only once it is trusted | JSON over stdio, before or after agent-loop stages | 33 events; `command`, `http`, `mcp_tool`, `prompt` and `agent` handlers |
| Project instructions | `AGENTS.md` | Rules; reads `AGENTS.md` and `CLAUDE.md` too | `CLAUDE.md`; reads `AGENTS.md` when there is no `CLAUDE.md` (v2.1.277+) |
| Default model | GPT-6.1 Sol (since 2026-09-29) | Pick per session; no single default (Hobby uses Auto; Cursor, checked 2026-10-12) | Claude Opus 5.5 (v2.1.280+) |

Codex and Claude Code facts are checked against `codex --help` 0.157.1, `claude --help` 2.1.283 and the vendors' docs on 2026-09-26. Some cells were re-read on 2026-10-12: the Codex GitHub, GitLab, Slack and Linear rows against OpenAI's Codex docs (OpenAI's Slack page is now titled "Use ChatGPT in Slack"), the Codex cloud, worktree and hooks cells against `codex --help` 0.162.1 and OpenAI's source for that release (the command list is identical to 0.157.1), and the Claude Code `AGENTS.md` fallback against Anthropic's memory docs and the `stable` release (2.1.287). The Cursor column comes from Cursor's docs, help pages and release notes, read on 2026-10-12 against Cursor 3.24. Three Cursor cells rest on pages read on 2026-10-13: the VS Code-based editor (Cursor's VS Code migration page), Cloud Agents in isolated VMs (the Cloud Agents page) and hooks as JSON over stdio (the hooks page). The Codex desktop app launches with `codex app` on macOS and Windows; according to Neowin it became a Codex mode inside the ChatGPT desktop app on 2026-07-09.

## Which tool should you use for each task?

Pick by where the task starts and how much supervision it needs, not by which model is "smarter".

| Task | Use | Why |
| --- | --- | --- |
| Bug reported in a Slack thread or Linear issue | Codex | `@ChatGPT` in Slack (with Cloud delegation) or `@Codex` in Linear starts a cloud task from the thread; nobody changes tools |
| Review of every pull request | Codex or Cursor | `@codex review` with automatic reviews, or Bugbot. Run one bot per repository, not both |
| Small edit in the file you have open | Cursor | Tab and inline edit keep you in the file; there is nothing to delegate |
| UI change you judge by looking at it | Cursor | You accept or reject each change as the dev server reloads |
| Change across 10 or more files with tests as the oracle | Claude Code or Codex CLI | Both run long in a worktree; Claude Code's richer hooks enforce the gate after every edit |
| Guardrails that must never be skipped | Claude Code, then Codex | Both run hooks and support managed policy; Claude Code has more events and handler types |
| Scripted job or CI step | Claude Code or Codex | `claude -p --output-format json`, or `codex exec --output-schema` for a typed result |
| Recurring maintenance (dependency checks, flaky-test triage) | Any | Codex automations, Cursor Automations, Claude Code Routines. Compare triggers, secrets and billing, not the feature name |

**Models.** Codex runs GPT-6.1 Sol by default at `low` effort (Codex's label: "Latest workhorse model for coding and everyday work."), you choose GPT-6 Astra ("Frontier intelligence for the most demanding work.") by hand for the hardest work, and GPT-6 Luna ("Fast and affordable model for easier tasks") covers cheaper, easier tasks. Claude Code runs Claude Opus 5.5 by default; you choose Claude Fable 5.1 by hand (`/model fable`) for the longest-horizon work. On the official Terminal-Bench 4.0 leaderboard (read 2026-10-12), Claude Opus 5.5 at max effort in Claude Code scores 64.8% ± 3.1 and GPT-6.1 Sol at max effort in Codex 58.2% ± 3.1; each runs in its own vendor's harness. An earlier version of this page said that neither Astra nor Opus 5.5 had an entry on 2026-09-26; GPT-6 Astra had been on the board since 2026-09-03. Start on each tool's default, raise effort before you switch model, and switch only when your own evals say so. Model prices and benchmarks live on the [models hub](/en/ecosystem/models/); plan prices for all three tools live on the [pricing analysis](/en/comparison/pricing-analysis/).

## How does one delegated task look in each tool?

The task: the auth tests fail on `main` and must be fixed before a release. The workflow differs; the acceptance criteria do not. Each prompt names the scope, the command that proves success and the report it must return.

**Codex**

    Start the task in Codex cloud from your terminal, so it runs on a remote environment you have already configured. The `codex cloud` command is marked experimental in CLI 0.157.1–0.162.1, so check `codex cloud --help` after each upgrade. Codex takes the environment ID and, by default, your current branch.

    **Copy-paste prompt: fix failing tests as a Codex cloud task**

    ```bash
    codex cloud exec --env ENV_ID "The tests in tests/auth/ fail on main.
    Run npm test -- tests/auth and find the root cause of each failure.
    Fix the code, not the tests, unless a test contradicts the behaviour
    described in docs/auth.md; in that case stop and explain.
    Do not touch files outside src/auth/ and tests/auth/.
    Finish with: root cause, files changed, and the full output of
    npm test -- tests/auth after the fix."
    ```

    Replace `ENV_ID` with an environment ID from `codex cloud`. Follow the task with `codex cloud status TASK_ID`, read the diff with `codex cloud diff TASK_ID`, and apply it locally with `codex cloud apply TASK_ID` only after the test output in the report is green. The same request works as an `@ChatGPT` mention in the Slack thread when your workspace has Cloud delegation enabled; OpenAI's docs say ChatGPT then sends the repository work to a Codex Cloud task and returns the result to the thread. Cloud delegation requires a published environment shared with the workspace (OpenAI's Slack page, read 2026-10-12).

**Claude Code**

    Start a session in its own worktree so the fix cannot collide with your other work, and let your project hooks run the gate after every edit.

    ```bash
    claude --worktree fix-auth-tests
    ```

    **Copy-paste prompt: fix failing tests in Claude Code**

    ```text
    The tests in tests/auth/ fail on main. Run npm test -- tests/auth and
    find the root cause of each failure. Fix the code, not the tests, unless
    a test contradicts docs/auth.md; in that case stop and ask me.
    Stay inside src/auth/ and tests/auth/.
    Finish with a table: failure, root cause, file changed, and the output
    of npm test -- tests/auth after the fix.
    ```

    To start the same work from Slack or GitHub instead, use Claude Tag or the Claude Code GitHub Action; see [Claude Code Routines](/en/claude-code/automate/routines/) for scheduled runs.

**Cursor**

    Hand the task to a Cloud Agent, or run it in a worktree from the Agent panel if you want to watch it. The prompt is the same contract.

    **Copy-paste prompt: fix failing tests with a Cursor Cloud Agent**

    ```text
    @tests/auth @docs/auth.md
    The tests in tests/auth/ fail on main. Plan first, then fix the root
    cause of each failure in src/auth/. Change a test only if it contradicts
    docs/auth.md, and tell me when you do. Touch nothing outside src/auth/
    and tests/auth/. Run npm test -- tests/auth before you finish and paste
    its full output with a list of changed files.
    ```

    Cursor Automations can start the same agent from a Slack message or a Linear issue; see [Cloud Agents and Automations](/en/cursor-ide/automate/cloud-agents-automations/).

What makes each result checkable is the shared contract: a scope boundary, one test command, a rule for when to stop, and a required report. See [acceptance criteria an agent can verify](/en/workflows/plan/acceptance-criteria/) for how to write it.

## How do you verify Codex's output without reading every line?

Codex produces changes from places where nobody watches the run: a Slack thread, a Linear comment, a scheduled automation. Someone then turns the result into a pull request. So the gate has to work without a human in the loop. Use the same gate you use for Cursor and Claude Code.

1. **Put the review rules in `AGENTS.md`.** Codex reads `AGENTS.md` before it works, and OpenAI's GitHub docs say custom review rules for `@codex review` go in a `## Code Review Rules` section there too (read 2026-10-12). One file then steers both the author and the reviewer. Since Codex 0.150.0, untrusted projects do not supply project-level `AGENTS.md`, so trust the repository before you rely on it.

   **Copy-paste prompt: focused Codex review on a pull request**

   ```text
   @codex review Focus only on:
   1. authentication and session handling in src/auth/
   2. error paths that return a different shape than src/lib/errors.ts defines
   3. database queries added without an index or a limit
   For each finding give the file, the line, the failure it causes and the
   test that would catch it. Skip style comments.
   ```

2. **Make Codex report evidence, not a summary.** For scripted runs, `codex exec --output-schema` forces the final answer into a JSON shape that CI can check. Save this as `evidence.schema.json`:

   ```json
   {
     "type": "object",
     "additionalProperties": false,
     "required": ["criteria", "commands", "unverified"],
     "properties": {
       "criteria": { "type": "array", "items": { "type": "object",
         "additionalProperties": false,
         "required": ["criterion", "test", "passed"],
         "properties": { "criterion": { "type": "string" }, "test": { "type": "string" }, "passed": { "type": "boolean" } } } },
       "commands": { "type": "array", "items": { "type": "object",
         "additionalProperties": false,
         "required": ["command", "exit_code"],
         "properties": { "command": { "type": "string" }, "exit_code": { "type": "integer" } } } },
       "unverified": { "type": "array", "items": { "type": "string" } }
     }
   }
   ```

   Codex sends this schema to the API in strict mode, so every object needs `"additionalProperties": false` and every property must be listed in `required`. Without them the run fails with a schema error and writes no `evidence.json`.

   Then run the evidence pass on the branch, in the terminal, with a read-only permission profile (beta, Codex CLI 0.138.0 or later). The `:read-only` profile allows no network access and no file writes, so fetch the acceptance criteria first and hand them to Codex as a file:

   ```bash
   gh pr view --json body -q .body > pr-criteria.md
   codex -c default_permissions=":read-only" exec \
     --output-schema evidence.schema.json -o evidence.json \
     "Compare this branch with origin/main. For each acceptance criterion in
     pr-criteria.md, name the test that proves it and whether it passed.
     List every command you ran with its exit code. If a check cannot run
     without network access or without writing files, put it under
     unverified. Do not report a check as passed unless you ran it."
   ```

   If your test runner writes caches or coverage files, those tests fail under `:read-only`; run this pass with the `:workspace` profile instead.

   Then let CI check the report instead of a person:

   ```bash
   jq -e '(.criteria | length > 0) and ([.criteria[].passed] | all)' evidence.json
   ```

   `jq -e` exits non-zero when the list is empty or any criterion is `false`, so the job fails. The file is the agent's own claim, though, and a pull request can edit it, so this check only catches a run that admits a failure; the gate is CI re-running the tests itself (step 4). A reviewer reads `evidence.json` and the files listed under `unverified`, not every hunk.

3. **Let a different agent review.** A reviewer that did not write the change does not share its blind spots. When Cursor or Claude Code wrote the branch, `codex review --base main` gives you that second opinion locally. When Codex wrote it, ask Claude Code or Cursor.

   **Copy-paste prompt: Claude Code reviewing a branch Codex wrote**

   ```text
   Review the diff between origin/main and HEAD. Codex wrote it; you did not.
   Check it against the acceptance criteria in the PR description and the
   rules in AGENTS.md. Report only:
   1. behaviour the tests do not cover (name the missing test)
   2. changes outside the scope the PR description states
   3. any test that was edited to make it pass
   Rank findings by risk. Do not restate what the code does.
   ```

4. **Let CI decide.** Tests, type check and lint run on every pull request, whichever agent opened it, and nothing merges on a red check. In CI, never run an agent on an untrusted contributor's ref while secrets are in the environment; the safe pattern is in [automated PR review](/en/workflows/ship/agent-pr-review/).

**Who signs off.** The person who started the task, including from Slack or Linear, owns the pull request and reads the evidence, the flagged files and any high-risk finding. The tech lead owns the gate: which checks run, which reviewer bot is on, and which paths (auth, payments, migrations) always need a human. The [evidence bundle](/en/workflows/ship/evidence-bundle/) defines a complete change manifest.

## Where does each tool cost you?

**Codex.** More surfaces mean more places to configure and govern. A task started in Slack runs in a cloud environment with its own dependencies and secrets, which can differ from your laptop. Admins constrain the CLI through `requirements.toml` (for example `allow_managed_hooks_only` and `permission_profile`), so treat that file as part of your platform, not a personal setting. Plan allowances run on five-hour and weekly windows, and Pro plans currently have no five-hour limit (OpenAI's Codex pricing page, read 2026-10-12).

**Cursor.** The editor is the centre, so unattended work goes through Cloud Agents and Automations, which you set up separately from interactive use. Cursor's plan prices are in the [pricing analysis](/en/comparison/pricing-analysis/) (cursor.com/pricing, read 2026-10-12), and Bugbot bills by usage: an average run costs between $1.00 and $1.50, according to Cursor's help (checked 2026-10-12).

**Claude Code.** It has the richest hook and policy model, and also the most concepts to learn: permission modes, Routines, background sessions, Claude Tag and plugins. Release channels matter: `stable` runs about a week behind `latest` (v2.1.292 against v2.1.302 on 2026-10-17), so a feature from v2.1.293 or later is on `latest` only.

For tech leads and CTOs deciding whether to add Codex, adopt this table as-is:

| Question | Adopt this answer |
| --- | --- |
| Do we add Codex as a third tool? | Only if work arrives in GitHub, Slack or Linear and your company already has ChatGPT plans that include Codex. Otherwise the extra surfaces cost more governance than they save. |
| What do we standardize? | The gate: `AGENTS.md` rules, CI checks, one review bot per repository, and the evidence format. Any tool that passes the gate is allowed. |
| What do we measure? | Cost per accepted change and revert rate per tool, not tasks started. See [the economics of agent-built software](/en/strategy/economics/). |
| Who controls permissions? | The platform team, through managed settings: `requirements.toml` for Codex, managed settings for Claude Code. See [permissions and sandboxing](/en/workflows/harness/permissions-and-sandboxing/). |
| How do we pick a winner? | Run the same 10 to 20 of your own closed issues through each tool against the same gate, then compare accepted changes and cost. The protocol is in [the coding-agent landscape](/en/comparison/agent-landscape/). |

## What breaks when you add Codex next to Cursor or Claude Code?

**Two review bots comment on every pull request.** Symptom: `@codex review` and Bugbot, or Claude Code's action, post overlapping findings, and reviewers start ignoring both. Recovery: pick one PR review bot per repository and use the other tools for pre-PR review only.

**A cloud task passes in the cloud and fails locally.** Symptom: the report shows green tests, but `codex cloud apply` produces a branch that fails CI. Recovery: make the cloud environment install the same dependency versions as CI, and treat CI, not the task report, as the source of truth.

**Instructions drift between `AGENTS.md`, `CLAUDE.md` and Cursor Rules.** Symptom: each agent follows different conventions in the same repository. Recovery: keep `AGENTS.md` as the single source and let every tool read it: Cursor reads it natively (Cursor's rules docs, checked 2026-10-12), and Claude Code reads it where there is no `CLAUDE.md` or through an `@AGENTS.md` import. See [rules sync across tools](/en/ecosystem/frameworks/rules-sync/).

**A Codex hook never fires.** Symptom: the lint hook you committed does nothing in Codex. Recovery: Codex runs a hook only after it is trusted; review and trust it in the session (`/hooks`). If your admins set `allow_managed_hooks_only`, project hooks are ignored by design and the hook belongs in managed policy.

**A task from Slack changes more than it should.** Symptom: a "fix the failing test" request edits the test to pass. Recovery: put "fix the code, not the tests" and the stop rule in `AGENTS.md`, and add a CI check that flags modified or deleted assertions in existing test files (new tests pass freely) and routes those pull requests to a required CODEOWNERS or human approval.

**Someone enables full access to unblock a run.** Symptom: `--dangerously-bypass-approvals-and-sandbox` appears in a script. Recovery: remove it. Use it only inside a disposable, network-restricted sandbox. For unattended local runs, use `--approve-for-me` (automatic review with the workspace-write sandbox) or a permission profile.

## Where to go next after comparing Codex

- [Migrating between Codex, Cursor and Claude Code](/en/teams/adopt/from-codex/) — Move instructions, MCP servers and habits between tools
- [Cursor vs Claude Code](/en/comparison/cursor-vs-claude-code/) — The two-tool comparison, with a shared hook-enforced gate
- [Feature matrix](/en/comparison/feature-matrix/) — The detailed capability table for all three tools
- [Pricing analysis](/en/comparison/pricing-analysis/) — Current plan prices for all three tools in one place
- [Codex in Slack and Linear](/en/codex/automate/slack-linear-integration/) — Set up the integrations that make Codex different
- [Codex cloud environments](/en/codex/automate/cloud-environments/) — Configure the environment your cloud tasks run in