Claude Code vs Cursor vs Copilot: Compare the Handoff, Not the Chatbox

Claude Code, Cursor, and GitHub Copilot no longer occupy three tidy categories. Each can participate in an editor loop, an agentic repository change, and some form of remote work. The useful comparison is not which chatbox feels smartest. It is where a work packet executes, what authority crosses with it, and what artifact returns for review.

That changes the buying decision. A terminal-first engineer may reasonably prefer Claude Code for one repository while a team standardizes Cursor for an editor-centered loop and enables Copilot's cloud coding agent for a narrow issue-to-pull-request lane. Those are not contradictory rankings. They are three handoff contracts. The failure is buying a product name before defining the contract.

We replaced the old feature-and-price roundup with a decision memo and a deterministic local routing drill. The host does not have Claude Code, Cursor CLI, or the GitHub Copilot CLI extension installed. No product session, repository read, repository mutation, credential, or model call was made. The drill evaluated 49 declared work packets across local and cloud execution, repository binding, permission policy, network and secrets policy, review evidence, editor and terminal constraints, multi-repository work, and GitHub-native issue-to-PR handoff. All 49 matched their expected result across 23 distinct outcomes: 15 ready, 15 held, and 19 blocked.

The old comparison mixed four different jobs

Autocomplete, an editor agent, a terminal agent, and a cloud branch worker are different operating modes. They may share a model or brand, but they do not share the same blast radius or review surface. Autocomplete proposes a few tokens into a file already open. An editor agent can search, edit, and run commands inside a local workspace. A terminal agent may own a much wider repository loop. A cloud worker starts in another environment and returns a branch, pull request, logs, screenshots, or some combination of those artifacts.

The legacy article compared those modes as though they were interchangeable features, then declared a “best fit.” It also quoted plan prices without reproducing a trial or counting reviewer time. That is not enough for a 2026 procurement decision. Product surfaces move quickly, plan entitlements change, and the expensive part of a failed coding-agent rollout is rarely the seat alone. It is an ambiguous handoff that produces plausible code without a trustworthy route back to the reviewer.

Start with one sentence that names the work:

Change one repository at a bound revision,
inside a declared execution environment,
with explicit tool and network authority,
and return a diff, tests, logs, and a review owner.

Until the team can complete that sentence, it has no basis for comparing Claude Code vs Cursor vs Copilot.

The same task changes when it crosses the handoff

A local editor task inherits the developer's checkout, ignored files, uncommitted changes, installed tools, and whatever credentials are already reachable. That can be wonderfully efficient. It also means the trial must say whether the agent may inspect untracked files, write outside the repository, use the shell, open a browser, or reach a development database.

A cloud task has the opposite problem. Isolation is clearer, but the environment must be reconstructed. Dependency installation, private package access, test services, network allowlists, secrets, repository permissions, and branch rules stop being invisible workstation facts. A “bad agent result” may really be an incomplete environment contract. Conversely, a cloud result that passes only after granting broad network and repository access may be too expensive to trust.

The returned artifact matters just as much. A local agent can leave a dirty worktree and a transcript. A remote agent may return a branch or pull request. Checkpoints inside an editor can help recover an interaction, but they are not necessarily durable project history. Cursor explicitly distinguishes its local checkpoints from Git; Git remains the permanent history. A serious evaluation records what survived a restart, what another reviewer could reproduce, and which artifact was authoritative when the transcript and repository disagreed.

A terminal-first lane favors visible command ownership

Claude Code's documented center of gravity is a command-line agent that can read code, edit files, and run commands. The same system also has IDE, desktop, and web surfaces, so calling it “the terminal option” is incomplete. The terminal remains a useful decision constraint when engineers already work through shells, repository scripts, and explicit command review.

Its permission model is more important than the interface. Claude Code documents read-only defaults for some tools, prompts for Bash and edits under normal settings, and ordered deny, ask, and allow rules. It also documents modes such as Plan, Accept Edits, and more permissive modes. Those rules are enforced by the Claude Code application rather than by a sentence in a prompt file. Managed settings can disable risky modes. That gives a team something concrete to test: a denied command must stay denied even when repository text asks for it.

The web surface is a separate lane. Claude Code on the web runs in an Anthropic-managed virtual machine with a fresh clone and persistent session state. Repository instructions, hooks, settings, skills, and permitted integrations may enter that environment; local workstation files do not. Its GitHub setup documentation carries a subtle warning: connecting the account can expose repositories visible to that account, so the app installation is not a complete session-level access boundary. Restricting account membership and repository access remains part of the design.

Use this lane when the terminal is the team's normal control surface and command-by-command authority is reviewable. Do not choose it from a benchmark score alone, and do not assume its web session has the same permissions or evidence as its local CLI.

An editor-centered lane makes the diff the conversation

Cursor's Agent is documented as an editor-resident system that searches a codebase, edits files, uses a shell and browser, and can handle complex tasks. That integrated loop is valuable when the developer wants to inspect a diff next to the code and interrupt or redirect the agent without translating everything through a terminal transcript.

Cursor rules can be versioned with the project and scoped to files or applied by intent. They are useful shared context. They are not a substitute for an operating-system or cloud permission boundary. A repository rule that says “never access production” is still text provided to the model. The evaluation must separately test whether production credentials, networks, or tools are reachable.

Cursor's cloud agents belong in another row of the decision. The official documentation describes isolated virtual machines, source-control branches, environment configuration, saved snapshots, network controls, secret handling, remote inspection, and artifacts such as screenshots, videos, and logs. It also supports several source-control providers and multi-repository work. That may be a better fit than a GitHub-specific cloud worker when the task crosses repositories or providers, but only after the environment, branch, secret, and outbound-network contract is configured.

Use the editor lane when the team's dominant correction loop is “inspect the current diff, adjust locally, and keep driving.” Use the cloud lane when a reconstructed environment and branch handoff are deliberate. Do not count them as one capability in a checklist; they carry different evidence and failure modes.

A GitHub-native lane can make the pull request the unit of work

GitHub Copilot also spans local IDE agent mode and a cloud coding agent. GitHub's own documentation says these are distinct: IDE agent mode works in the developer's local environment, while the cloud coding agent works in a GitHub-hosted environment and produces branch and pull-request evidence.

The cloud agent can begin from an issue or other GitHub surface, research the repository, plan a change, run tests and linters in an ephemeral GitHub Actions-powered environment, commit to a branch, and open or update a pull request. Commits and logs give reviewers familiar evidence. For a team that already treats an issue, branch, checks, code review, and merge policy as one controlled workflow, that native handoff can be more important than which model generated the patch.

The administrative boundary is not optional. For GitHub Business and Enterprise organizations, GitHub documents the coding-agent policy as disabled by default until an administrator enables it. Repositories can be excluded, and automation policies have additional scope. A procurement trial should test the org policy, repository opt-out, branch protection, Actions environment, secret exposure, and whether a reviewer can reconstruct the run without privileged access to somebody else's workstation.

Use the GitHub-native lane when the pull request is the durable unit, issue-to-PR delegation is intentional, and organization policy is already part of repository governance. Do not call it the “safest default” merely because the repository is on GitHub; safety comes from the enabled policy, environment, permissions, branch controls, and review behavior.

Rules, permissions, and environment controls are different layers

Every product lets a team provide instructions. Instructions improve consistency, but they do not all enforce authority at the same layer. This distinction is easy to lose in a feature table.

A polished demo can satisfy the first row while failing every other row. That is why “supports project rules,” “runs commands,” or “opens pull requests” should never be treated as a sufficient procurement result.

Testing the routing policy without running the products

The local fixture used a deliberately conservative decision function. Every packet first had to bind a repository and worktree, success evidence, a review artifact, permission policy, and a human reviewer. Cloud packets also needed explicit permission to use cloud execution, a configured environment, network policy, and secrets policy.

After those gates, a genuinely terminal-first packet could select a Claude local lane if the client was available. A packet requiring a dedicated editor could select a Cursor editor lane. A GitHub-native issue-to-PR packet could select Copilot's cloud lane when the organization policy was enabled. Multi-repository or non-GitHub cloud work could select a configured Cursor cloud lane. A declared preference for the Anthropic-managed cloud surface could select Claude web when enabled.

Most important, a packet with two equivalent eligible surfaces did not get a winner. It returned hold_run_repository_trial. A missing client returned an installation hold. A missing environment returned a configuration hold. An unbound repository, review, permission, network, secrets, or evidence contract blocked before selection.

The 49 cases matched their declared outcomes: 15 ready, 15 held, and 19 blocked across 23 decision types. That does not rank the products. It establishes a more defensible routing rule: product selection comes after the handoff contract, and an ambiguous contract remains ambiguous.

Run one repository trial with deliberately awkward tasks

A fair trial needs the same starting revision, acceptance criteria, test commands, environment access, and reviewer. It should contain work that exposes boundaries rather than rewarding a memorized framework edit.

Use three tasks. The first should be a narrow bug with a failing test and one expected file boundary. The second should cross several modules and require a design trade-off. The third should include an instruction or fixture that tries to expand scope, reach a forbidden network, read a secret, or edit a protected file. Do not make the attack theatrical; a stale setup script or misleading repository note is closer to production.

For every eligible lane, record:

• time until the first reviewable diff, not time until the first confident paragraph;
• commands and tools actually executed, including denied attempts;
• files, repositories, networks, services, and secrets the run could reach;
• test failures introduced, discovered, fixed, or left unexplained;
• number and cause of human correction loops;
• whether the run survived interruption or restart without losing the authoritative state;
• quality of the final diff, commits, checks, logs, screenshots, and explanation;
• reviewer minutes through acceptance or rejection.

Repeat the boundary cases after a product update. A beautiful result from one version does not prove that a managed permission, cloud network control, or source-control integration behaves the same later.

Requirements for a cost comparison that survives the invoice

Public plans are still relevant, but a static article is a poor authority for fast-changing prices and entitlements. Use each vendor's current plan page during procurement. Then add the costs the invoice does not show.

The reviewed-task cost includes the seat or request allowance, cloud execution charges where applicable, setup and environment maintenance, failed or abandoned runs, reviewer time, and the cost of reproducing an ambiguous result. A cheaper seat that doubles correction time can be the expensive option. A more capable cloud surface that requires broad repository or network access may carry a governance cost that no per-request price captures.

Measure enough tasks to see a distribution. Median time hides the long tail where agents stall on environment setup, tests, or permission prompts. Track the ninety-fifth percentile reviewer burden and the fraction of tasks rejected after a superficially successful run.

A practical default is three bounded lanes

For a team starting now, a sensible policy is smaller than a winner-takes-all rollout:

1. Local synchronous lane. One approved editor or terminal surface, repository-bound, with explicit tool prompts, no production credentials, and a human owning the live diff.
2. Cloud branch lane. One reconstructed environment, narrow repository access, explicit network and secret policy, isolated branch, required tests, and pull-request review. Enable only for task classes that benefit from asynchronous work.
3. Hold lane. Tasks with unclear scope, cross-repository authority, missing tests, missing environment definition, sensitive data, deployment access, or ambiguous review ownership do not get routed to another agent “just to try.” They wait for a better contract.

Claude Code, Cursor, and GitHub Copilot can each occupy more than one lane. The team does not need to pretend their boundaries are identical, and it does not need to crown one product across every type of work.

Conclusion: the handoff comes before the product

The official documentation establishes that all three products span more than the stereotype attached to their names. Claude Code includes terminal, IDE, desktop, and web surfaces with application-level permission controls. Cursor includes an editor agent and isolated cloud agents with environment, network, secret, branch, and artifact concepts. Copilot separates local IDE agent mode from a GitHub-hosted cloud coding agent governed by organization and repository policy.

The local fixture establishes only that one declared routing policy returned its declared result for 49 synthetic packets. The host probe establishes that Claude Code, Cursor CLI, and the Copilot CLI extension were not available here. It does not establish model quality, patch correctness, latency, price, security certification, or developer preference. No product was asked to read or change a repository.

That boundary is intentional. The old article converted overlapping feature pages into a universal ranking. The replacement gives teams a way to produce their own evidence without confusing a chat experience with a permission model or a successful patch with a controlled handoff.

The right answer to Claude Code vs Cursor vs Copilot is therefore a routing policy, not a podium. Bind the task. Bind the environment. Bind the authority. Require a reviewable artifact. Then let a repository trial decide the remaining tie.

Primary sources

• Claude Code overview
• Claude Code permissions
• Claude Code on the web
• Claude Code IDE integrations
• Cursor Agent overview
• Cursor cloud agents
• Cursor rules
• Cursor security
• GitHub Copilot cloud coding agent
• GitHub Copilot coding-agent access management
• GitHub Copilot IDE agent mode