Cursor vs VSCode on a Mac: what moves and what stays the same

Most comparisons of Cursor and VS Code were written when the difference was obvious: one had an AI agent built in and the other did not. That gap closed. VS Code now ships an agents window, subagents, MCP, hooks, plugins, automations, and terminal sandboxing. Cursor still has a faster loop and a more opinionated one. The decision no longer turns on capability.

What it turns on instead is three things that are easy to check and rarely checked: where extensions come from, who bills for model usage, and what each editor does by default with a folder it has never seen before. Everything else transfers.

The parts that stay the same

Cursor is built on VS Code, which is why switching feels like nothing at all for the first hour. Keybindings carry over. The command palette behaves the same way. Settings files have the same shape, tasks and launch configurations work, the integrated terminal is the integrated terminal, and remote development over SSH or containers works the way it always did.

That is the honest baseline and it matters for a specific reason: the switching cost in either direction is low, which means the decision does not have to be permanent, and treating it as permanent is what turns a small choice into a long argument. Both editors can be installed on the same Mac, pointed at the same repository, and used on the same afternoon.

What does not transfer is the muscle memory of which pane the AI lives in and which shortcut summons it. That is a week of friction, not a month.

The agent feature list has largely converged too, which is the reason the older comparisons read as dated. Both sides now offer custom instructions, reusable skills, subagents, MCP servers, hooks, and a plan-then-execute mode that lets an approach be reviewed before any file is touched. Both can review a diff, both keep session history, and both can hand a task to something that keeps running when the editor closes. A feature-by-feature table between them in 2026 is mostly a list of ties, which is exactly why a comparison built on one is not much help in deciding.

Extensions are the one place the fork really shows

This is the concrete difference most comparisons skip, and it is documented on both sides.

VS Code installs extensions from the Visual Studio Code Marketplace, browsable from the Extensions view with Shift+Cmd+X. Cursor uses the Open VSX registry instead, with a marketplace proxy that runs automated malware and supply-chain analysis before an extension is offered for install. Cursor's own documentation states the consequences directly: most popular extensions are on Open VSX, but not every Microsoft Marketplace extension is listed there, and for the ones that are unavailable Cursor publishes first-party Anysphere replacements.

The sharpest line in that documentation is about naming. The same publisher.extension identifier can point to different publishers or different code on Open VSX than on the Microsoft Marketplace. The advice that follows is to treat extension IDs like dependencies and install from publishers that are actually trusted.

For most work this is invisible. For a team with a locked list of approved extensions, or a language stack that depends on a Microsoft-published extension, it is the whole decision. It takes ten minutes to check: list the extensions currently relied on, then look for each one on Open VSX before committing to anything.

What each one costs, and who bills for the model

Both editors are free to download. The money is in model usage, and the two route it differently.

	Cursor	VS Code
Editor	Free to download	Free to download
Free tier	Hobby, with limited agent requests	Copilot Free, with a monthly allowance of inline suggestions and AI credits
Paid individual	$20 per month	Copilot Pro at $10 per month, Pro+ at $39, Max at $100
Team plan	$40 per user per month	Priced through GitHub Copilot business plans
Bring your own model key	Available on paid plans	Supported, with the provider handling billing
Extension source	Open VSX plus a vetting proxy	Visual Studio Code Marketplace

Cursor's prices are quoted exclusive of tax, and every plan includes a set amount of model usage with on-demand usage billed afterwards once the allowance runs out. On the VS Code side, signing in without an existing Copilot plan enrolls an eligible account in Copilot Free, and usage is metered in AI credits against whichever plan applies.

The bring-your-own-key row deserves more attention than a price comparison usually gives it. In VS Code a Claude key, a ChatGPT subscription, or other model credentials can be used directly, and in that arrangement the model provider manages usage and billing rather than the editor vendor. For anyone already paying a frontier provider for a subscription that includes generous limits, that changes the arithmetic completely, because the editor cost drops to zero and the model cost is already sunk.

The usage dashboard is the thing worth watching either way. Both editors meter credits, and a long agent run consumes them at a rate that is hard to intuit from the price on the pricing page.

Approvals and sandboxing: the real 2026 difference

If one section decides this, it is this one, because the two editors have arrived at genuinely different defaults for the same problem.

Cursor governs autonomy through Run Modes, set under Settings, Agents, Approvals and Execution. Auto-review runs allowlisted calls immediately, sandboxes other shell commands where possible, and sends the rest to a classifier running on a small Cursor-managed model. Allowlist mode is deterministic and narrow. Run Everything asks nothing. Cursor's documentation states plainly that Auto-review is not a security boundary and that the classifier can err in both directions.

VS Code approaches it as two separate layers and says so: approvals decide whether an action runs at all, and sandboxing restricts what an approved terminal command can reach on disk and over the network. Terminal sandboxing on macOS is in Preview behind chat.agent.sandbox.enabled with no additional prerequisite, while Linux and WSL2 need bubblewrap and socat installed and Windows support is still experimental. The sandbox covers terminal commands and their child processes, not the built-in file tools.

The defaults for an unfamiliar folder diverge further, and this is the part worth knowing before cloning something from a stranger.

VS Code opens a new, unfamiliar folder in Restricted Mode to prevent automatic code execution while the contents are reviewed, and that trust state is shared between the editor window and the agents window. An untrusted workspace means agents do not run in either place.

Cursor supports workspace trust but ships it disabled, and its documentation notes that Restricted Mode breaks the AI features, recommending a plain text editor for a repository nobody trusts yet. Turning it on means adding "security.workspace.trust.enabled": true to user settings.

Neither default is wrong. They encode different assumptions about the user. VS Code assumes the folder might be hostile. Cursor assumes the person opening it already decided it is not.

There is a gap common to both that no setting closes. Sandboxing applies to terminal commands and the processes they spawn. It does not apply to the built-in file tools, which means an agent writing files through its own edit tool is outside the sandbox in either editor. On the Cursor side, the commands most worth containing are also the ones that cannot be contained, since anything needing writes outside the workspace or privileged access falls through to the classifier rather than into the sandbox. The conclusion is the same in both: version control, not a setting, is what makes an unwanted edit reversible.

Where a session runs, and how changes are isolated

Both editors now let an agent run somewhere other than the current folder, and the mechanisms differ in a way that affects review.

VS Code exposes a Session Target control that picks the harness and the location: Copilot for general coding, Local when the task needs VS Code built-in tools or extension tools or a model configured in the editor, Claude or Codex when that provider's workflow fits better, and Cloud for a scoped task that runs against a GitHub repository and returns a pull request. Alongside it sits a code isolation control that chooses between the current folder and a new Git worktree. Worktree sessions run with all actions allowed, and the documentation is careful to say that a worktree isolates code changes but is not a security boundary.

Cursor's equivalent is the side pane opened with Cmd+I, the agent command in the terminal with its Agent, Plan, and Ask modes, and a cloud handoff triggered by prefixing a message with &, which keeps the task running after the laptop closes. For work spanning many files there is also a Project, where a coordinating agent plans and delegates to others.

The practical difference is in how a review starts. A worktree hands over a separate checkout with a clean diff against committed state. An in-place session hands over changes already written to the working directory. Both are reviewable. Only one of them is reviewable after closing the laptop and forgetting what the state was.

What neither one fixes

Both editors assume the interesting content is inside one project folder. On a real Mac it is not.

A single task tends to involve a repository, a specification in a notes app, an export landing in Downloads, a reference file on an external disk, and a terminal opened somewhere else to check what the export actually contains. The editor sees the folder it was opened on. The arrangement around that folder stays a manual job, which is why the switch between the folder view and the shell is the move that gets repeated fifty times a day regardless of which editor won the argument.

A file manager with a built-in terminal addresses that surrounding layer rather than the editing, and being clear about the division matters: it does not compete with either editor on writing code. What it removes is the window switching and the retyped paths. The scope of that is set out under features, and the places where a dedicated editor is simply the better tool are stated without hedging in the comparison.

The second unsolved piece is time. An agent session that runs for twenty minutes needs somebody available when it stops to ask a question, not somebody watching it for twenty minutes. Reaching the Mac from an iPhone or iPad turns a blocked afternoon into a short reply from wherever the reply happens.

What to change first

Check the extension list against Open VSX before switching, and check who is billing for model usage before comparing monthly prices, because a bring-your-own-key setup changes the answer. Then look at the layer neither editor touches: the folder view and the shell sitting in separate windows, which is what Atriens is built to collapse.