Install Cursor and migrate your VS Code setup

You’ve cloned budgetcli, you’ve spotted the date bug in the CSV importer, and you have no agent yet. Getting Cursor onto your machine is a download and a couple of clicks — but unlike the other tools in this course, the install lesson here has real substance, because Cursor replaces your editor rather than bolting onto it. The thirty minutes you spend here is mostly about carrying your VS Code setup across cleanly and understanding the one place where the fork can’t follow you: where extensions come from.

Download the desktop app

Cursor is a standalone desktop application — a fork of VS Code built by Anysphere — not an extension you add to an editor you already have. You download it the way you’d download any app: grab the installer for your OS from cursor.com, run it, and launch. There’s a build for macOS, Windows, and Linux. Because the exact download surface and supported platforms shift over time, treat cursor.com/docs as the source of truth for the current installer on your machine.

Open it once it’s installed. What you’ll see on first launch is, deliberately, almost exactly VS Code — same Activity Bar down the left, same Command Palette behind Cmd/Ctrl+Shift+P, same editor surface. That familiarity is the whole point of the fork, and it’s why your muscle memory survives the move. What’s added — the Agent sidebar and Tab — is the subject of a later lesson; for now we just want the editor furnished the way yours already is.

Carry your VS Code setup across

Because Cursor inherits VS Code’s configuration model, almost everything from your existing setup can come with you in one move. On first launch Cursor offers this as an onboarding prompt, and you can run it any time afterward from settings.

The one-click VS Code Import brings over four things — Extensions, Themes, Settings, and Keybindings — from a detected VS Code install. You reach it from Cursor Settings (Cmd/Ctrl+Shift+J) under General → Account → VS Code Import, where an Import button does the transfer in a single step.

Two inheritances are worth calling out because they keep working without any import step at all:

• Your user settings.json is honoured, and so is a project’s .vscode/settings.json. On macOS, Cursor’s own user settings live at ~/Library/Application Support/Cursor/User/settings.json — the same shape as VS Code, in Cursor’s own application-support folder.
• Your keybindings carry over with the import, and project-scoped settings checked into budgetcli’s .vscode/ directory are read exactly as VS Code would read them.

So when you open budgetcli in Cursor for the first time, the editor already looks like the one you closed: your theme, your tab width, your format-on-save, your shortcuts. That’s the part the fork gets for free.

The one thing the fork can’t carry: where extensions come from

Here’s the inheritance that doesn’t come across, and it’s the most likely thing to trip you up on day one. Extensions do not come from Microsoft’s marketplace. Microsoft’s marketplace terms prohibit third-party clients, so Cursor can’t connect to it. Instead, Cursor’s Extensions panel is backed by Open VSX, the open extension registry.

The practical consequence: most popular extensions are on Open VSX, but coverage is meaningfully thinner than upstream VS Code, and some extensions simply never ship there. When you run the import above, the extensions that exist on Open VSX install cleanly; the handful that don’t will quietly fail to appear, and that’s the gap you need a fallback for.

The fallback is side-loading a .vsix. A .vsix is just the packaged extension file. For an extension that isn’t in Cursor’s panel, you download its .vsix from a source you trust and install it from disk — Cursor reads the file the same way the marketplace would have handed it over.

Let’s make the gap concrete with a real one. Say budgetcli ships a .vsix for an internal linter — or you need a specific extension that’s marketplace-only. Download the .vsix, then install it from disk: the reliable path is the Command Palette (Cmd/Ctrl+Shift+P) → Extensions: Install from VSIX…, point it at the file, and reload.

You’ll do this once, for real, before the chapter is out. The reason it’s worth meeting now rather than discovering it mid-task is that the failure mode is silent: an extension you depend on just isn’t there after the import, and without knowing about Open VSX you’d waste twenty minutes assuming the import broke. It didn’t — that extension was never on Open VSX, and the .vsix is your way in.

Know the plan shape before the next lesson

Signing in is the next lesson’s job, but it’s worth seeing the plan shape now so the choice there is informed rather than rushed. Cursor’s individual tiers run from a free Hobby tier up through paid Pro, Pro+, and Ultra tiers; Teams (with its own sub-tiers) and Enterprise layer on admin controls — pooled usage, invoicing, and the security and policy settings an organization pushes from the Cursor dashboard.

The detail that matters for this hour: the free Hobby tier is enough to ship one reviewed change, so you can follow along without a card, and decide on an upgrade later with real usage in front of you instead of a guess. If you’re at a company on Teams or Enterprise, some of what you can do — which models are available, which features are on — is decided above your account by whoever administers the dashboard; we’ll flag the specific places that bites when they come up.

You’re furnished — now sign in

Cursor is installed, it’s open on budgetcli, and it looks like the editor you already know: your extensions imported (minus any Open VSX gaps you now know how to fill with a .vsix), your settings and keybindings carried across. What it doesn’t have yet is you — it doesn’t know who you are or which plan you’re on, and that sign-in choice shapes what the agent can do. Next: sign in and choose a plan.