Cursor vs Codex vs CritiqueCode
Three authoring surfaces, three contracts. Pick the IDE agent, OpenAI’s CLI and cloud loop, or a local author whose controller forces review and verified repair.
Cursor vs Codex vs CritiqueCode
IDE. OpenAI CLI. Forced review.
critique.sh
Choose Cursor if you live in the IDE and want Agent (Composer and other models) to search, edit, run the terminal, and checkpoint inside the editor. Choose OpenAI Codex if you want OpenAI’s agent CLI, with optional handoff into Codex cloud. Choose CritiqueCode if you want local authoring whose controller forces independent review and verified repair before “done” means anything. If you keep Cursor or Codex as the author, use the Critique CLI sidecar instead of switching agents.
“Cursor vs Codex” is a real shopping question in 2026. Both write code. Both can run commands. Both can review their own diffs. The useful split is where you sit (editor vs terminal vs OpenAI’s cloud loop) and whether the writer is allowed to grade the homework.
CritiqueCode is a third option: @critiquedotsh/harness (critique-code). It authors in a local session, then the Author Coordinator captures a Change Capsule and runs review the author cannot skip. It is not the Critique CLI sidecar (@critiquedotsh/cli, binary critique). Related: best coding agent 2026 and CritiqueCode vs Claude Code.
Cursor vs Codex vs CritiqueCode at a glance
| Dimension | Cursor | OpenAI Codex | CritiqueCode |
|---|---|---|---|
| Primary surface | IDE Agent (Cmd+I / Ctrl+I side pane), plus Cursor CLI and Composer inside Cursor. | Terminal CLI (codex); also IDE extension, desktop app, and Codex web/cloud. | Local terminal author (critique-code) in the repo cwd. |
| Who authors | Cursor Agent with the model you pick, including Composer 2.5 (Cursor-only). | OpenAI Codex on ChatGPT sign-in or other documented auth; models chosen in-session (/model). | CritiqueCode author session. Specialists never author the product. |
| Review contract | You review diffs, checkpoints, and editor UX. Agent can keep calling tools until the task ends. | /review inspects uncommitted work, a commit, or a base branch without writing. Still the same product. | Controller forces local review after a claimed unit of work or write-budget trip. Author checks are never Evidence. |
| Repair / rollback | Local checkpoints before significant edits; restore in the chat timeline. Git remains the durable history. | Git checkpoints around a task; codex exec for scripts; codex cloud to apply remote work locally. | Verified repair may apply only if the coordinator allows it. Promotion stays on /review and /ship. |
| Best fit | You live in the IDE and want the write/run/fix loop next to the file tree. | You want OpenAI’s agent CLI, headless codex exec, and the CLI/cloud loop. | You want the author loop itself to include an independent challenge. |
| Package / binary | Cursor app (Agent + Composer). Not an npm author agent. | @openai/codex or the official installer; binary codex. | @critiquedotsh/harness; binary critique-code. Sidecar is @critiquedotsh/cli / critique. |
What Cursor Agent and Composer actually are
Cursor documents Agent as the assistant that can complete coding tasks, run terminal commands, and edit files from the side pane. Agent is instructions plus tools plus the model you pick. Tools include search, file read/edit, shell, web, rules fetch, browser control, and image generation. There is no published cap on tool calls per task.
Composer 2.5 is Cursor’s own agentic model. Cursor’s model docs describe it as tuned for long-horizon coding, tool use, file edits, and terminal work inside Cursor. Cursor’s Composer page states Composer 2.5 is available in the desktop app, web, CLI, and mobile, and that you can build agents on it with the Cursor SDK. Standard list price on that page is $0.50 per million input tokens and $2.50 per million output tokens, with a faster variant at $3 / $15 per million. Fast is the default in product. Those are Cursor’s published token rates, not a quality score.
Checkpoints snapshot modified files before significant Agent edits. They live locally, separate from Git. Cursor’s docs say to use them to undo Agent turns and to use Git for durable version control. Queued messages wait until the current turn finishes unless you send immediately.
What OpenAI Codex CLI actually is
OpenAI’s Codex CLI docs describe a local terminal agent: inspect files, edit, run the tools already on the machine, and stay in one loop. Install via the official script, npm (@openai/codex), Homebrew, or a GitHub release binary. First run: codex in a project directory, then Sign in with ChatGPT (or another documented method). ChatGPT Plus, Pro, Business, Edu, and Enterprise plans are the usual entitlement path OpenAI documents.
The CLI is interactive by default. codex exec is the non-interactive path for scripts and CI. You choose model, reasoning effort, and permissions (/model, /permissions). Codex also ships /review for a dedicated pass over uncommitted changes, a commit, or a base branch without modifying the tree. That is useful. It is still Codex reviewing Codex-shaped work inside the same product family.
OpenAI’s GitHub README splits surfaces: CLI for local terminal work, IDE extension for VS Code / Cursor / Windsurf, desktop app, and Codex Web at chatgpt.com/codex for the cloud-based agent. CLI docs include codex cloud to submit work to a configured environment and apply the result locally. If that CLI/cloud loop is what you want, Codex is the match. This post does not pitch Critique Cloud as an alternative.
What CritiqueCode actually is
CritiqueCode is Critique’s author agent. You run critique-code in the repository you want to edit. The model implements. After a claimed unit of work, or when the write budget trips, the controller captures a Change Capsule and runs local CritiqueCode review. Author transcripts and author check output are never Evidence. none_promoted is not a correctness proof.
The published package is @critiquedotsh/harness. The binary is critique-code. The Critique CLI sidecar is a different product: @critiquedotsh/cli, binary critique. Do not install one hoping to get the other. Do not call critique finish as a substitute for CritiqueCode.
Keep Cursor or Codex: use the Critique CLI sidecar
If Cursor or Codex is already the author you trust for speed, keep it. Install @critiquedotsh/cli and run Critique as the independent finish pass after the builder. That sidecar is for people who do not want to switch authoring tools. CritiqueCode is for people who want Critique to author, then refuse to let the author promote its own work.
Mixing the two binaries is the common failure. critique reviews. critique-code authors. Same npm org. Different jobs. See the CritiqueCode introduction for install defaults and commands.
- 1Do you live in the editor and want Agent next to the file tree?Use Cursor Agent (Composer 2.5 or another model Cursor supports). Add the Critique CLI sidecar if you want an independent finish pass.
- 2Do you want OpenAI’s terminal agent,
codex exec, and the CLI/cloud loop?Use Codex CLI (codex). Keep ChatGPT plan auth as OpenAI documents it. Add the Critique CLI sidecar if you want review outside Codex. - 3Do you want local authoring whose controller forces review and verified repair?Install
@critiquedotsh/harnessand runcritique-codein the target repo. - 4Are you happy with Cursor or Codex as the writer?Do not switch to CritiqueCode just to get review. Install
@critiquedotsh/cli(critique) as the sidecar.