Claude Code vs Cursor vs Codex: which AI coding agent to use

An AI coding AgentAgentA model that uses tools in a loop, deciding each next step from what the last one returned, until the task is done. works in your project the way a developer would: it reads files, changes them and runs commands such as your tests, checking the results until the task is done. Claude Code, Cursor and Codex all work that way, and on a well-described task they all get far. The differences that matter day to day are where you use each one, which models it runs, how you pay, and, most of all, how you limit what it may touch.

Claude Code

Claude Code is Anthropic's agent. It began in the terminal and now runs in VS Code, JetBrains, a desktop app and on the web, with the same settings everywhere. It uses Claude models only, paid through a Claude plan or per token through the Anthropic Console or a cloud provider. Its strength is control: permission rules per tool, such as allowing npm test while denying .env, several permission modes, subagentsSubagentAn agent started by another agent for one part of a task. It works in its own fresh context and returns only its findings., skills, hooks and plugins. The guide covers each one, starting at Claude Code, topic by topic.

Cursor

Cursor is a code editor built around AI, with the agent beside tab completion and inline edits. It also has a CLI, agent, and cloud agents that keep working while you are away. Cursor sells its own models in a weekly usage pool and, on Premium and above, other makers' models, Claude, GPT and Gemini among them, at their API list price. Its instructions are rule files that apply always, to matching files, or when the agent judges them relevant, and it reads AGENTS.md too.

Codex

Codex is OpenAI's agent: an open-source CLI, an IDE extension, the ChatGPT desktop app and cloud tasks, all using OpenAI's models and included in paid ChatGPT plans. It starts the most locked down of the 3. Commands run in an operating-system sandbox that limits writes to the project and turns the network off, with an approval policy deciding when it asks you, and permission profiles and rules files to adjust both.

Side by side

The same project, set up for each

Start with the instructions every agent shares. All 3 read an AGENTS.md at the project root, so a team using several agents keeps one copy of its conventions:

# Shop API

- Install with `npm ci`. Run `npm test` before you say a change is done.
- The code is TypeScript in `src/`; each test sits beside its file as `*.test.ts`.
- Never open or print `.env`. If you need a value from it, ask.
- Never push. Leave the branch for review.

An instruction is only guidance. A model can misread it, and text inside a file or web page it reads can try to override it, which is prompt injectionPrompt InjectionAn attack that hides instructions in text a model reads, such as a web page, an email or a file, so the model follows the attacker instead of you.. So each agent also gets a file that enforces the rules that matter.

{
  "$schema": "https://json.schemastore.org/claude-code-settings.json",
  "permissions": {
    "allow": ["Bash(npm test)", "Bash(npm run lint)"],
    "deny": ["Read(./.env)", "Read(./.env.*)", "Bash(git push *)"]
  },
  "sandbox": {
    "enabled": true,
    "filesystem": { "denyRead": ["./.env", "./.env.*"] }
  }
}

{
  "permissions": {
    "allow": ["Shell(npm:test)", "Shell(npm:run lint)"],
    "deny": ["Read(.env*)", "Shell(git:push*)"]
  }
}

approval_policy = "on-request"
default_permissions = "shop"

[permissions.shop]
extends = ":workspace"

[permissions.shop.filesystem.":workspace_roots"]
"**/.env*" = "deny"

The 3 files enforce them at different depths. Cursor's rules govern its CLI's own tools. Claude Code's rules cover its file tools and the commands it recognises, such as cat, and its sandbox, once enabled, blocks .env for every process a command starts. Codex's profile works at that same operating-system level from the start. When we ran the Codex profile, cat .env failed with "Operation not permitted", while writing a file inside src/ worked.

Codex keeps rules for commands in their own files. This one forbids pushing; match and not_match are examples Codex checks when it loads the file, so a wrong pattern fails at once. codex execpolicy check confirmed that git push origin main is forbidden and npm test is untouched:

# .codex/rules/default.rules
prefix_rule(
    pattern = ["git", "push"],
    decision = "forbidden",
    justification = "Leave the branch for review; never push.",
    match = ["git push", "git push origin main"],
    not_match = ["git status"],
)

Which to use

Things to watch

• Instructions are not limits. Anything that must never happen, such as reading secrets or pushing, belongs in permission rules or a sandbox, not only in AGENTS.md or CLAUDE.md.
• Keep instructions short. Every line is read on every task and takes room in the context windowContext WindowEverything a model can see at once while it writes an answer, counted in tokens. When the window is full, something has to be left out.. Codex stops adding AGENTS.md files at 32 KiB by default.
• Trust before project settings load. Codex ignores a project's .codex folder until you trust the project, and Claude Code asks before using files a project imports from outside it. A cloned repository's settings are someone else's choices.
• MCPModel Context ProtocolAn open standard for connecting AI applications to tools and data. A system offered once as an MCP server works in any application that speaks MCP. servers run with your access. All 3 can connect them. Add only servers you trust, and allow their tools one at a time.

To set Claude Code up for your own project, the settings builder writes the settings.json, MCP file and starter CLAUDE.md. To see what each Claude model costs per task, use the LLM cost calculator.