Cursor vs Codex: Editor Agent or OpenAI’s Coding Agent

Cursor and OpenAI Codex overlap more than their names suggest. Both have an agent in the editor, a command-line agent, cloud agents that hand back a branch, and a pull request reviewer. The difference is what sits at the centre. Cursor is an editor: the agent, the diff and your code share one window, and it runs models from several vendors. Codex is an agent: the same OpenAI agent appears in a terminal, in whichever editor you use, in the ChatGPT desktop app and in the cloud, all reading one AGENTS.md and one configuration. Choose Cursor if you want a single editor built around its agent. Choose Codex if you want one agent you can take between tools, including into Cursor itself, since the Codex extension installs there.

The surfaces, side by side

              Cursor                           Codex
Editor        Cursor (Agent, Plan, Ask)        extension for VS Code, Cursor, Windsurf
Terminal      agent                            codex
Desktop       Cursor, Agents Window            ChatGPT desktop app, Codex view
Cloud         cloud agents                     Codex cloud
Scripts, CI   agent -p                         codex exec
PR review     Bugbot                           @codex review

Cursor’s command-line agent is started with agent. Cursor’s CLI overview↗ (opens in a new tab) says it supports the same Agent, Plan and Ask modes as the editor, has a print mode for scripts and CI, and can push a conversation to a cloud agent by starting a message with &. What Cursor used to call background agents are now cloud agents: they run in isolated virtual machines with full development environments, clone from GitHub, GitLab, Bitbucket Cloud or Azure DevOps, and push a branch. You can start them from Cursor on the desktop, the web, the iOS app, Slack, Linear, the API or an @cursor comment.

Codex’s desktop experience is now the Codex view of the ChatGPT desktop app, where you choose Codex rather than ChatGPT for a new chat. Codex cloud runs tasks in OpenAI-managed containers and takes work from the web, GitHub, GitLab, Linear and Slack, as well as from the CLI and the extension. How the Codex surfaces divide the work is in Codex app vs CLI vs IDE extension.

Codex inside Cursor

This is not an either-or. OpenAI’s IDE extension page↗ (opens in a new tab) lists Cursor, with VS Code and Windsurf, as editors that run the Codex extension; open it from the Codex icon or the Command Palette. You then have two agents in one window: Cursor’s own, using Cursor’s rules and models, and Codex, using your Codex configuration and AGENTS.md. Cursor’s editor, Cursor’s tab completion and Codex’s agent is a reasonable arrangement if your team has standardised on Codex but you like the editor.

One rule makes it workable: do not let both agents edit the same branch at once. Give each its own task, and ideally its own worktree.

Instruction files: rules and AGENTS.md

• Cursor: project rules are .mdc files in .cursor/rules, each applied always, when the agent judges it relevant, to matching files, or when you @-mention it. A plain .md file there is ignored. Cursor also reads AGENTS.md as a simpler alternative, and a root CLAUDE.md. Rule types are in Cursor rules for AI projects.
• Codex: reads AGENTS.md from ~/.codex and from each directory between the project root and where you are, with AGENTS.override.md taking precedence in a directory. It does not read .cursor/rules.

So the shared ground is AGENTS.md. Put build commands, conventions and no-go areas there, and keep Cursor-only matters, such as a rule that applies to one file pattern, in .cursor/rules. The file-by-file map is in AI context files compared.

Approvals and sandboxing

Cursor frames this as run modes. Its run modes page↗ (opens in a new tab) lists Auto-review, where allowlisted calls run at once, other shell commands run in a sandbox where possible and a classifier reviews the rest; Allowlist, where only listed actions run unasked; and Run Everything. Cursor says plainly that Auto-review is not a security boundary. You can steer it with plain-English instructions in .cursor/permissions.json, and sandbox limits live in a separate sandbox.json. Checkpoints restore files, are stored locally and are separate from Git.

Codex starts from containment. OpenAI’s approvals and security page↗ (opens in a new tab) says the CLI and IDE extension enforce a sandbox at the operating-system level, with no network access and writes limited to the workspace by default. Two settings work together: the sandbox mode, which sets what a command can technically do, and the approval policy, which sets when Codex must ask. The Auto preset reads, edits and runs commands in the workspace and asks before leaving it. Automatic approval review can route those requests to a reviewer agent instead of you. OpenAI recommends Git checkpoints before and after a task.

# Cursor CLI
agent --mode=plan

# Codex CLI
codex --sandbox read-only --ask-for-approval on-request

The practical difference: in Cursor you mostly tune who reviews a risky call, you or a classifier. In Codex you mostly tune how far a command can reach before anyone is asked. Either way, a checkpoint rewinds files, not a migration that ran or a message that was sent.

Pull request review: Bugbot vs @codex review

• Bugbot: Cursor’s Bugbot documentation↗ (opens in a new tab) says it reviews pull request diffs automatically on each update, or when someone comments cursor review or bugbot run, on GitHub, GitLab, Bitbucket and Azure DevOps. It reads .cursor/BUGBOT.md files, the root one always and others near the changed files, and posts a check whose findings default to neutral unless your organisation turns on failing for unresolved issues.
• Codex: comment @codex review on a GitHub pull request, or turn on automatic reviews, once Codex cloud is set up for the repository. According to OpenAI’s GitHub review guide↗ (opens in a new tab), it posts a standard GitHub review that flags only P0 and P1 issues and follows a ## Code Review Rules section in the nearest AGENTS.md. The CLI’s /review does the same locally, before you push.

Either is a useful first reader of a pull request the other agent wrote. A person still approves; the routine is in AI agents for PR review.

Models and MCP

Cursor runs models from OpenAI, Anthropic, Google and others, plus its own, and you pick per chat. Codex runs OpenAI’s models, chosen with /model or --model. If you want OpenAI’s agent specifically, that is Codex; if you want to switch vendors between tasks, that is Cursor. They are billed differently; check each vendor’s current plans.

Both are MCP clients for local and remote servers. Cursor reads .cursor/mcp.json in the project or ~/.cursor/mcp.json, and its CLI uses the same file. Codex keeps servers in ~/.codex/config.toml, or a trusted project’s .codex/config.toml, which the CLI and extension share.

// Cursor: .cursor/mcp.json
{ "mcpServers": { "fenbs": { "url": "https://fenbs.ai/api/mcp" } } }

# Codex
codex mcp add fenbs --url https://fenbs.ai/api/mcp
codex mcp login fenbs

Who each suits

• You want one editor with the agent, the diff and tab completion built in, and freedom to switch model vendors: Cursor.
• You want OpenAI’s agent in every tool you use, with one AGENTS.md and one config.toml: Codex.
• You like Cursor’s editor but your team runs Codex: install the Codex extension in Cursor and keep shared rules in AGENTS.md.
• You want commands contained with the network off unless you allow it: Codex’s local default. Cursor can sandbox shell commands too, as a layer under its run modes.
• Your code is on Bitbucket or Azure DevOps: Cursor’s cloud agents and Bugbot support them. Codex cloud connects to GitHub and, in beta, GitLab.
• You want to fire off tasks from Slack or Linear and review later: both can.

One list of work for both

A Cursor chat, a cloud agent run and a Codex thread each record one tool’s part of the work, and none is where a colleague looks. Put the task on a fenbs board both can reach over MCP. Each signs in through your account, you tick what it may do, and every change is recorded in History under the assistant’s name on your behalf. A task a person has marked Pre-approved for AI can be taken with fenbs_next_approved_task and handed back with fenbs_release_task, so two agents never pick up the same one.