Claude Code vs Cursor vs Codex vs OpenCode (2026)

Four coding agents keep coming up in the same argument: Claude Code, Cursor, OpenAI Codex and OpenCode. The argument is usually framed as a winner-takes-all fight. It is not one. They overlap heavily, and the differences that matter to me are boring ones: where the thing runs, which models it will drive, how far you can extend it, and what you own at the end.

I build and run automations. n8n on a server, Docker Compose files, a reverse proxy, deploy scripts, the odd custom node. That is a different job from writing a React app, and it changes which of these tools I reach for. This post compares them on that basis.

Everything below was checked on 6 September 2026 against official documentation and package metadata. Where I could not verify something, I say so instead of guessing. These tools ship changes weekly, so check the current docs before you make a decision that costs money.

The One-Line Version

• Claude Code is Anthropic's agent. Terminal-first, with IDE extensions and a desktop app on top, driving Claude models, with the deepest built-in extension surface of the four.
• Cursor is an editor that is also a coding agent. The editor is the main surface, you pick between models from several vendors, and there is a CLI for the terminal and CI.
• OpenAI Codex is OpenAI's agent. Terminal-first with an IDE extension, Apache-2.0 licensed, with a config file that gives you real control over models, sandboxing and approvals.
• OpenCode is the open-source one. MIT licensed, provider-agnostic, a terminal interface with a desktop app and IDE extension, and it will point at a local model if you ask it to.

Comparison Table

Axis	Claude Code	Cursor	OpenAI Codex	OpenCode
Primary surface	Terminal	Editor	Terminal	Terminal (TUI)
Other surfaces	VS Code and JetBrains extensions, desktop app	CLI (agent), TypeScript SDK	IDE extension for VS Code, Cursor, Windsurf	Desktop app, IDE extension
Models	Claude models	Several vendors plus Cursor's own	OpenAI models by default	Any provider you configure
Point at your own endpoint	Provider options documented (Bedrock, Foundry and others)	Routes through Cursor's service	Yes, via model_providers and base_url	Yes, via OpenAI-compatible providers
Project instructions file	CLAUDE.md	AGENTS.md	AGENTS.md	AGENTS.md
MCP servers	Yes	Yes	Yes	Yes
Hooks / lifecycle events	Yes, ten documented events	Plugins and skills	Hooks and rules, project-scoped	Plugins
Subagents	Yes	Agent features in editor and CLI	Delegation documented	Yes, built-in Build/Plan plus subagents
Permission model	Six named modes plus allow/ask/deny rules	Approval prompts, --approve-mcps	approval_policy plus sandbox_mode	permission config with allow/ask/deny
Non-interactive mode	claude -p	agent -p	codex exec	opencode run
Licence	Proprietary	Proprietary	Apache-2.0	MIT
Install checked today	@anthropic-ai/claude-code 2.1.263	curl https://cursor.com/install -fsS | bash	@openai/codex 0.153.4	opencode-ai 1.18.29

Two notes on that table. First, "any provider you configure" for OpenCode means the provider has to speak a supported API shape, not that every model on earth works well. Second, licence is about what you can fork and inspect, not about which tool writes better code. I have no defensible way to measure the second thing, so I do not claim it.

Claude Code

Claude Code runs in your terminal. You start it in a project directory and talk to it. It reads files, edits them, runs commands, and asks permission on the way through. I checked the version on my own machine today with claude --version and got 2.1.263. The npm package is @anthropic-ai/claude-code, and its licence field points at the README rather than an open-source licence, so treat it as proprietary.

What stands out is the extension surface. There is a CLAUDE.md file for persistent project instructions, path-scoped rules under .claude/rules/, skills that load only when used, subagents that run with their own context, and hooks that fire on ten documented lifecycle events including PreToolUse, PostToolUse, SessionStart and SubagentStop. MCP servers connect over stdio, SSE, HTTP or WebSocket.

The permission system is the part I use most. There are six modes: default (labelled Manual, reads only), acceptEdits, plan, auto, dontAsk, and bypassPermissions. Shift+Tab cycles between them. Deny rules block in every mode, including bypassPermissions, which is the guarantee that makes the whole thing usable on a machine with credentials on it.

Good at: long multi-file work where you want to control exactly what the agent may touch, and setups you want to encode in files and commit.

Cursor

Cursor is an AI editor and coding agent. Its own docs describe it as a tool for understanding codebases, planning and building features with Plan Mode, finding bugs, and reviewing changes, customisable with plugins, skills, MCP servers and rules. It integrates with GitHub, GitLab, Azure DevOps, Bitbucket, JetBrains, Slack and Linear.

The editor is the reason people pick it. If you want to see the diff inline, click into a file, and stay in one window, Cursor is built for that and the other three are not.

It also ships a CLI, installed with curl https://cursor.com/install -fsS | bash, which gives you agent. That runs interactively or non-interactively:

agent -p "review these changes for security issues" --output-format text

You choose the model with /model in a session or --model on the command line. The docs show auto, gpt-5 and sonnet-4-thinking as examples, and the TypeScript SDK exposes ids such as auto-smart and composer-2.5. So model choice is real, but it goes through Cursor rather than through your own API keys and endpoints.

One line in the Cursor CLI docs is worth reading twice: in non-interactive mode, the agent has full write access. That is fine in a container and less fine on your laptop.

Good at: visual review of what the agent changed, and anyone whose day is already spent in an editor.

OpenAI Codex

Codex CLI is OpenAI's local coding agent. The repository is Apache-2.0 and the npm package @openai/codex was at 0.153.4 when I checked today. You can install it with the official script, with npm install -g @openai/codex, or with brew install --cask codex. There is an IDE extension for VS Code, Cursor and Windsurf.

The configuration is the interesting part for anyone who runs their own infrastructure. Personal defaults live in ~/.codex/config.toml, with project overrides in .codex/config.toml that only load when you trust the project, plus profiles and an optional system-wide /etc/codex/config.toml. Organisations can enforce constraints through a requirements.toml, for example disallowing approval_policy = "never" or sandbox_mode = "danger-full-access".

Two settings do most of the work:

approval_policy = "on-request"
sandbox_mode = "workspace-write"

approval_policy controls when Codex stops to ask, with untrusted, on-request and never as the documented values. sandbox_mode controls what the filesystem and network let it do. You can also define entries under model_providers with your own base_url and wire format, then set model_provider to point at them, which is how you route Codex through a proxy or a compatible endpoint of your own.

For automation, codex exec is the non-interactive entry point, meant for scripts and CI.

Good at: scripted and CI use, and teams that want the sandbox and approval policy written down in a file an admin can enforce.

OpenCode

OpenCode is the open-source option. The repository is MIT licensed, the npm package opencode-ai was at 1.18.29 today, and the project now lives at github.com/anomalyco/opencode (the old sst/opencode URL redirects there). It is available as a terminal interface, a desktop app and an IDE extension, and it installs through a script, npm, Homebrew, pacman, Chocolatey, Scoop, mise, or a Docker image.

Provider-agnostic is the design goal. You bring API keys for whichever LLM providers you want. There is a curated list called OpenCode Zen if you do not want to choose. And you can define custom providers in opencode.json using the OpenAI-compatible SDK, with worked examples in the docs for LM Studio and llama.cpp running locally. That is the clearest path to a local model of the four.

Agents come in two shapes. Primary agents are the ones you talk to, and it ships with Build (all tools enabled) and Plan (file edits and bash both set to ask). Subagents are specialised assistants a primary agent can invoke, or you can call with an @ mention, and it ships General, Explore and Scout.

Permissions are a config block rather than a mode switch, and they go granular:

{
  "$schema": "https://opencode.ai/config.json",
  "permission": {
    "bash": {
      "*": "ask",
      "git *": "allow",
      "rm *": "deny"
    }
  }
}

There is an --auto flag that approves anything not explicitly denied, and opencode run for non-interactive use.

Good at: anyone who wants to read the source, run a local model, or keep the whole toolchain inside their own infrastructure.

And GitHub Copilot

Copilot deserves a mention because plenty of people search for the comparison and because plenty of people already pay for it. It started as inline completion in the editor and now includes a terminal CLI, installed as @github/copilot (1.0.83 today) or through Homebrew and WinGet. Running copilot opens an interactive session. It takes --model (the docs list auto, claude-sonnet-4.5 and gpt-5 as examples), --mode with interactive, autopilot or plan, and --worktree to start in a fresh git worktree. It requires a GitHub account with an active Copilot subscription.

If your work already lives in GitHub issues and pull requests, Copilot is the shortest path from a ticket to a branch. It is a fair default, and for a lot of people it is the only one they need.

Four Short Scenarios

You maintain one long-lived repo and you want the agent's rules committed alongside the code. Claude Code. The CLAUDE.md file, the rules directory, the subagent definitions and the hooks all live in the repo, so the setup travels with the project and reviews like any other change.

You want to see every diff before it lands, in a window, with the file tree next to it. Cursor. Reviewing an agent's work in a terminal is workable but it is not pleasant, and Cursor is the one built around that view.

You are wiring an agent into CI, or you work somewhere that needs the sandbox policy written down and enforced. Codex. codex exec plus approval_policy and sandbox_mode in a config file, with requirements.toml on managed machines, is the most administratively legible of the four.

You want to read the code, avoid vendor lock-in, or run a model on your own hardware. OpenCode. MIT licence, provider-agnostic config, and documented local-model providers.

If none of those describe you, the honest answer is to pick whichever one you already have a subscription for.

The Automation Builder's Workflow

Here is where the comparison stops being abstract. My work is not a monorepo of application code. It is a server running n8n, a compose file, a Caddy config, some deploy scripts, and a pile of workflow JSON. The agent's job is the plumbing around n8n, not the workflows themselves.

Three things actually matter for that job.

One: the agent has to run where the code runs. Compose files, .env files and deploy scripts are terminal work. Every one of these four has a terminal path now, so this is no longer a differentiator, but it is why terminal-first tools feel natural for infrastructure work and editor-first tools feel natural for application work.

Two: you have to be able to stop it doing the wrong thing. An agent with shell access on a box that has your n8n encryption key and your Postgres password is a real risk. All four have a way to constrain that, and they are worth learning properly:

• Claude Code: permission modes plus deny rules that hold in every mode.
• Codex: sandbox_mode and approval_policy in config.toml.
• OpenCode: the permission block with per-command patterns.
• Cursor: approval prompts, and remembering that -p mode has full write access.

My rule is simple. Deny anything that touches secrets, and never let an agent run a destructive command against a production volume. Our security practices for workflow automation covers the wider version of that argument.

Three: MCP is how the agent sees your real systems. All four support MCP servers. That is the mechanism that lets an agent query your database, read your monitoring, or hit an internal API instead of guessing. For automation work this is the single feature that changes the quality of the output, because the agent stops writing plausible config and starts writing config that matches what is actually running.

What none of them do well is edit n8n workflow JSON by hand. The node graph format is verbose and position-sensitive, and I have had better results asking an agent to write the Code node body, then pasting that into the editor. If you are building the workflows themselves, our guides on building AI agents with n8n and the Docker Compose self-hosting setup are the more useful starting point.

They Overlap More Than The Debate Suggests

Look at what all four now have. A terminal mode. A non-interactive mode for scripts. A project instructions file. MCP server support. Subagents or an equivalent. A permission or approval system. Plan-first behaviour before edits. Three of the four use AGENTS.md for the same purpose.

The convergence is not an accident. These are all agentic loops over a similar tool set, and good ideas move between them quickly. Whichever one you pick, the skills transfer. Writing clear instructions, scoping a task, reviewing a diff, and refusing to grant permissions you do not need are the same skills in all four.

So the choice matters less than the debate implies. It matters most at the edges: licence, model choice, and whether the surface you want is a terminal or an editor. Pick on those. Then spend your time getting good at the workflow rather than switching tools.

What I Could Not Verify

In the interest of not making things up:

• Pricing. All four change plans and limits regularly. I did not check a single price today, and I am not going to publish numbers I have not read this morning. Check each vendor's pricing page.
• Performance and quality comparisons. I have no benchmark I trust across these four on real automation work. Public leaderboards measure something, but not this. Anyone quoting a percentage should show you their method.
• Context window sizes and specific model names beyond what the docs show as examples. These move monthly. The Codex config docs currently use model = "gpt-5.6" in their example, and the Cursor and Copilot docs list model ids as examples rather than as a complete supported list. Read the current model page for whichever tool you pick.
• Anything about a tool's roadmap. Not verifiable, so not stated.

If a claim in this post has gone stale, it probably has. Tell me and I will fix it. More about what House of Loops is and who writes this on the about page.

---

Once you have picked one, the next question is how to use it without producing a pile of code you cannot review. That is the subject of the follow-up: Claude Code best practices for builders. There is also a free Claude Code for Builders course in the House of Loops classroom that walks through the setup on a real automation project.