I will say something many people will not agree with: for a site, the choice between Claude Code, Codex and Cursor means less than it seems. All three can read a project, change files and run commands. All three are sometimes wrong. And the result depends most of all on two things that have nothing to do with the choice of tool: how clearly the task is set, and how carefully a person checks the changes.
That does not mean there is no difference. There is, and it is mostly about where the tool lives and how you work with it: in the terminal, in the editor or in the cloud. That decides who it is more convenient for and how to check what it did. That is what we will talk about. There will be no ready ranking: I did not run a comparative test on one task, so instead of a winner I will explain why it is worth comparing on your own task and by which criteria.
How they are alike and why they get mixed up
Claude Code, Codex and Cursor are AI agents for working with code. Unlike a chat, where you copy code back and forth, an agent works directly with the project files: it reads them, suggests changes, makes edits and runs commands in the terminal.
They get mixed up for understandable reasons. The tasks are similar for all of them: write a new block, fix an error, remake a page. The capabilities overlap: Claude Code and Codex have extensions for editors, and Cursor has an agent that runs commands. And all three change quickly, so a description from half a year ago may already not match reality.
An important shared trait: each of the tools reads a file of instructions for the project. Claude Code reads CLAUDE.md at the start of every session, Codex reads AGENTS.md before work, Cursor supports its own project rules in the .cursor/rules folder and also understands AGENTS.md. That file records how the project is built, which commands to run, what must not be touched. This is one of the most useful things in working with any agent.
Where each tool lives
Claude Code
Claude Code from Anthropic is originally a tool for the terminal. Now, according to the documentation, it works in the terminal, in editors (VS Code and JetBrains), in a separate desktop application and on the web. It can work with git: make commits, create branches, prepare merge requests.
Most ways of working need a Claude subscription or an Anthropic Console account.
Who it suits: people who are used to the terminal or ready to get used to it, and people who want the agent to handle git while a person checks the result.
Codex
Codex from OpenAI exists in several forms. Codex CLI works in the terminal: the /init command creates an AGENTS.md file for the project, and /permissions sets what the agent is allowed to do without confirmation. The editor extension lets you view edits right in the code and undo them. Codex Cloud runs tasks in the cloud with repositories on GitHub or GitLab: you set a task and get the result while you do something else.
How independently the agent works is a separate decision. The more it does without confirmation, the faster the work, but the more carefully the result has to be looked at. So the agent’s freedom is widened gradually, as it becomes clear how it works with a particular project.
Codex is available on ChatGPT plans (Plus, Pro, Business and others).
Who it suits: people who already use ChatGPT, and people who need to hand a task to the cloud and come back to the result later.
Cursor
Cursor is a code editor with AI built in. The agent in the side panel can edit code and run commands in the terminal. Before significant changes Cursor makes checkpoints — snapshots of files that you can return to. Project rules are stored in the .cursor/rules folder, and AGENTS.md is supported too.
Who it suits: people who want to see the code and the agent’s edits in a familiar editor window and have a simple rollback at hand.
| Feature | Claude Code | Codex | Cursor |
|---|---|---|---|
| Main place of work | Terminal | Terminal, editor, cloud | Code editor |
| Other options | Editors, app, web | Editor extension | An agent in the editor with a terminal |
| Instruction file | CLAUDE.md | AGENTS.md | .cursor/rules, AGENTS.md |
| Work with git | Commits, branches, merge requests | Cloud tasks with repositories | Through the editor and the terminal |
| Rolling edits back | Through git | Undo in the editor, git | Checkpoints, git |
| Access | A Claude subscription or Console | ChatGPT plans | A Cursor account |
Why a ranking will not replace a check on your own task
Reviews and rankings are useful for learning about capabilities. But for a choice, a comparison on a typical task of a particular project works best: not the simplest and not the hardest, clear and checkable. The conditions have to be the same — the same copy of the project, the same wording of the task, the same instruction file. Otherwise what is compared is not the tools, but who was explained to in more detail.
The result also has to be judged by the same criteria: whether the task was solved in full, whether all the changes are to the point, whether what worked was broken, how many clarifications were needed, how easy the edits are to check. This is where the boundary runs: to compare tools honestly, you need to be able to read changes in the code and understand why one solution is more reliable than another. Without that skill the comparison turns into a choice by feeling. Convenience matters too: a tool that writes code a little better but works in an environment where edits are inconvenient to check can in practice give a worse result.
How a tool changes files and how to check it
Any agent will sooner or later do something other than what is needed: fix an extra file, delete a needed line, solve the task the wrong way. So what matters is not how often it is wrong, but how quickly you notice it and roll it back.
A diff is a list of changes: which lines were deleted, which were added. All three tools show changes, but differently: Cursor and the editor extensions show them right in the editor window, the terminal versions in the terminal or through git. A diff has to be looked at always, even if the task seems simple.
Commits. If the project is under git, each finished task should be a separate commit. Then any of them can be undone without touching the rest. Claude Code can make commits itself, but a person still has to check their content.
Rollback. Cursor has checkpoints, the Codex extension has undo of edits in the editor, and all of them have git. So before each task the current state of the project must be saved.
If the agent went the wrong way, a series of clarifications on top of unsuccessful edits usually only makes it more tangled. It is more reliable to roll back to the saved state and restate the task taking into account what went wrong. Each new edit on top of a mistake increases the diff that will then have to be checked.
A check in the browser. For a site, the diff is half the check. The other half is to open the page, look at it on a computer and on a phone, and check the forms and the interactive elements. An agent can write code that looks right in the diff and breaks the layout on a narrow screen.
What suits a beginner, and what suits someone who runs a project
A beginner who has not worked with code before usually finds it simpler to start with an editor: the files are visible, the edits are visible, there are undo buttons. The terminal is frightening at first, although there is nothing complicated in it. But honestly: if you do not understand code at all, none of the three tools will remove the need to understand what is happening in the project. The agent writes the code, but deciding whether it is right will be up to you.
It is reasonable to get to know any of the tools on small tasks where the result is easy to check. But even on those you need to understand what the agent changed and why, otherwise the mistake will surface later and in another place.
For someone who runs a project and understands how it is built, something else matters more: how well the tool works with a large project, how it follows the rules from the instruction file, whether a task can be handed to it and returned to later. Here it is worth looking at the terminal and cloud options, which let you work on several tasks in parallel.
If several people run the project, a single place for the rules matters. The AGENTS.md file is supported by both Codex and Cursor, so shared rules are convenient to keep there, and for Claude Code to duplicate them or refer to them from CLAUDE.md.
What a person checks
Whatever the tool, a person answers for:
- setting the task: what exactly must be done and what must not be touched;
- checking the changes: the diff, the page in the browser, the mobile version;
- safety: the agent must not get access to passwords, keys and client data without need;
- decisions about the architecture: how the project is built and what changes in it;
- publication: what goes out to the live site, and when.
The agent can suggest a solution on each point, but responsibility for the result stays with a person.
New dependencies are worth watching separately. An agent easily suggests connecting one more library to solve the task faster. Each such library is code that has to be updated and that may stop being maintained. For a small site it is often simpler to solve the task without it, and that is worth writing directly into the project instructions.
What I put into a project before work with any of the three
Preparation saves more time than the choice of tool. Before the first task, an instruction file appears in the project: how the project is built, which commands run the build and the check, what must not be touched. Tasks are cut into small parts, each with a clear way to check it and a separate commit. Limits are written explicitly, and the plan of changes is discussed before the edits: a mistake in the plan is simpler to fix than one in the code.
Safety is separate. Passwords and keys are kept in the environment settings and never get into the text of the task. And the result of each task is checked in the browser at once, not at the end of the day: the earlier a mistake is found, the simpler it is to see which edit caused it. All of this is not about a particular tool, but about how to run a project in which part of the code is written by AI.
If the project is more complicated than can be calmly run with an agent on your own, it can be handed to custom development. And if the task is an application inside Telegram, look at Telegram Mini App development. The project can be discussed through the quiz on mara-craft.com: I will look at the task and suggest where to start.