Claude Code, Codex and Cursor: what actually differs

All three read AGENTS.md. All three run Agent Skills in the same format. All three connect MCP. The feature comparison, the whole subject of 2025, ended in a tie.

The difference left over is more interesting and less discussed: where each one keeps persistent context, and when it decides to load it. That is where your working day changes.

Before any table, the scope.

This is a comparison of the official documentation of the three products, read and cited. It is no controlled test. I measured no speed, counted no completed tasks, and never ran the same problem through all three to see who solves it best.

Comparing coding agents without a methodology is opinion wearing the costume of data, and the market is full of that. The honest thing available is comparing what each vendor documents, because that is verifiable and it is what decides how you organize the project.

The size of the change is worth recording. A year ago, choosing a coding agent meant choosing a closed configuration ecosystem. Today:

Anthropic created the Agent Skills format and released it as an open standard. Today it shows up in the list of compatible clients alongside Cursor, Gemini CLI, Copilot, OpenCode, Goose and dozens of others.

The practical effect for anyone writing one: a well-made skill holds in all three. Stay inside the spec's six fields (name, description, license, compatibility, metadata and allowed-tools) and it is portable. Using a client-specific field is what locks you in.

The full format sits in how to write your first Agent Skill, including the six fields that guarantee portability.

This is the difference that changes the day-to-day, and the three solve it in distinct ways.

Claude Code, a hierarchy that concatenates. It walks up the directory tree from the current directory and joins everything it finds: managed policy, user, project and local. The files do not override each other, they add up, in order from the root down. The official target is under 200 lines per file, because all of it enters the context of every session. Anything past that goes to .claude/rules/ with paths or becomes a skill.

Cursor, four trigger types. Project rules live in .cursor/rules as .mdc files, markdown with frontmatter. And here is the difference in model: the frontmatter defines when the rule enters.

Note the second one. "Apply Intelligently" hands the agent the call on its own rule's relevance, something CLAUDE.md lacks, because there everything loads always. It is a different model of context economy: instead of you deciding what always loads, the agent decides what is pertinent right now.

Cursor also accepts AGENTS.md as a simple alternative, with no metadata, and it supports nesting: an AGENTS.md in a subdirectory gives more specific instruction for that area of the code. Ordinary .md files get ignored, and only AGENTS.md escapes that rule.

Codex, AGENTS.md as central configuration. The documentation describes the file as defining the agent's behavior and capabilities. It is the leanest model of the three.

The direct comparison is worth having:

The anatomy of a CLAUDE.md that works details the four scopes and what to do when the file goes past the ceiling.

The SKILL.md is identical. The paths each one searches are not.

Cursor looks in two paths per level, and one of them is .agents/skills/, the open standard's neutral directory. That carries a good practical consequence: a skill installed there gets found by both clients with no duplication.

Cursor also has frontmatter fields of its own that Claude Code never uses, such as icon and color for custom mode badges, and a /migrate-to-skills command for converting existing rules into skills.

And there is a precedence asymmetry worth knowing if you maintain both: in Claude Code, a personal skill overrides a project skill, while a project subagent overrides a personal subagent. Same folder structure, inverted behavior between the two features.

Subagents: when to delegate and when not to walks through the asymmetry.

Supported in all three, with documentation of differing depth.

Claude Code documents the most public detail: three installation scopes with defined precedence, four transports, environment variable expansion in .mcp.json, output limits with explicit numbers, and a tool search mechanism that defers the tool definitions.

Codex and Cursor document MCP support without that level of public specification. That does not mean they implement less, it means an honest comparison on that axis cannot be made from documentation.

It is the kind of limit a serious comparison has to declare instead of filling with assumption.

The details on the Claude Code side sit in MCP in practice.

Here is the deepest distinction I found, and it is no feature difference. It is a difference in which layer the restriction happens.

Codex splits it into two independent axes. sandbox_mode defines what it is capable of doing; approval_policy defines when it has to ask.

And the point that changes the nature of the guarantee: the operating system enforces the restriction. Seatbelt with sandbox-exec on macOS, bwrap plus seccomp on Linux, a dedicated sandbox on native Windows, Linux semantics on WSL2. Paths such as .git, .agents and .codex stay read-only regardless of mode.

Claude Code has both layers, with different defaults. The enforcement one arrives on: permissions.deny in the settings blocks a tool, command or path, and the six permission modes (default, acceptEdits, auto, dontAsk, bypassPermissions and plan) define how much it asks. The client applies configuration rules regardless of what the model decides, and a PreToolUse hook exiting with code 2 gives you a deterministic block.

The operating system layer exists too, and it is optional. The Bash sandbox uses Seatbelt on macOS and bubblewrap on Linux and WSL2, with the OS applying the limit to every command and every child process. It does not cover native Windows. You turn it on with /sandbox.

That is where the real difference shows up, and it is one of defaults, not of capability: in Codex the sandbox is the initial state, in Claude Code someone has to choose to turn it on. The breakdown of each layer and how they combine sits in permissions and auto mode.

An OS sandbox is harder to work around; application permission is easier to tune case by case. Anyone running an agent in a sensitive environment leans toward the first; anyone needing fine rules per command, the second.

For Cursor, I found no public documentation of comparable depth on that axis. As with the other points in this post, I would rather record the absence than fill it with assumption.

Documented surfaces:

Codex describes the widest range: desktop application, CLI, IDE extension, cloud environment, web interface and remote connections.

Claude Code runs in the terminal, in a desktop application, on the web and in IDE extensions.

Cursor is, at origin, an editor. The surface is the IDE itself.

Models:

Here sits a structural difference. Codex uses OpenAI models, with selection according to the use case. Claude Code uses Claude models. Cursor positions itself as model agnostic.

That is the only difference on this list that survives the next release: Cursor is the only one of the three that is not a lab's official client. If vendor independence is a criterion for you, it carries weight here.

I will not say which is best, because I did not test the three under controlled conditions and nobody should trust anyone who says so without having tested.

The offer instead is decision criteria, anchored in what the documentation states:

If your context is large and stable, the Claude Code model favors you: a hierarchy that concatenates, predictable, with scope by path for what is not universal.

If your context is large and situational, Cursor's four-trigger model addresses that head on, above all the "Apply Intelligently" mode, which has no equivalent in the other two.

If you work across varied surfaces (terminal one day, cloud the next, IDE on the third), Codex's list is the longest I found documented.

If model vendor independence is a requirement, Cursor is the only one positioning itself that way.

And if you already have skills written, the answer is comfortable: inside the open spec's six fields, they work in all three. The choice became reversible, which was not true a year ago.

Which of the three is best?

I do not know, and be suspicious of anyone answering without showing a methodology. This post compares what the three document, not what they deliver under test. The most relevant documented difference is the context model, and it favors different project profiles.

Does my skill work in all three?

If it uses only the six fields of the Agent Skills spec (name, description, license, compatibility, metadata and allowed-tools), yes. A client-specific field, such as Claude Code's context: fork or Cursor's icon, ties the skill to that client and can even fail at packaging time.

Can AGENTS.md and CLAUDE.md be used together?

They can, and it is the recommended pattern. Claude Code never reads AGENTS.md itself, so the way out is a CLAUDE.md importing it with @AGENTS.md, and Next.js 16 generates that same pair on its own when it detects an agent in the environment.

Is migrating Cursor rules to skills worth it?

Cursor offers the /migrate-to-skills command for that, with one documented caveat: rules with alwaysApply: true or with specific glob patterns keep behavior of their own. Migration makes more sense for what is procedure than for what is permanent convention.

• Anthropic — Claude Code Docs: How Claude remembers your project. Accessed 19 August 2026.
• Anthropic — Claude Code Docs: Extend Claude with skills. Accessed 19 August 2026.
• Anthropic — Claude Code Docs: Connect Claude Code to tools via MCP. Accessed 20 August 2026.
• Cursor — Skills. Accessed 20 August 2026.
• Cursor — Rules. Accessed 20 August 2026.
• Codex — Official documentation. Accessed 20 August 2026.
• Codex — Agent approvals & security. Accessed 20 August 2026.
• Anthropic — Claude Code Docs: Settings. Accessed 20 August 2026.
• Anthropic — Claude Code Docs: Configure the sandboxed Bash tool. Accessed 20 August 2026.
• Agent Skills — Open specification. Accessed 19 August 2026.

Verified on 20 August 2026.

Correction (2 October 2026): the original version stated that Claude Code's restriction lives "in the client" and Codex's "in the operating system". That was wrong. Claude Code has a sandbox with OS enforcement for Bash, via Seatbelt and bubblewrap. The difference between the two is which layer arrives on by default, not which of them exists. Corrected in the text and in the table.

Method note: this comparison uses the official documentation of the three products and nothing else, read in full in the sections cited. There was no controlled test, no speed measurement and no run of the same task in all three. Where one product's documentation allows no comparison with the others, that is declared in the text instead of filled by assumption.

Review trigger: revisit when any of the three changes its context loading model, when the Agent Skills spec accepts more fields, or when a public benchmark with an open methodology comparing the three appears.