Install Cursor and migrate your VS Code setup

This lesson goes from nothing installed to Cursor open on a repo - the course’s illustrative budgetcli (a small self-hosted budgeting API), or any TypeScript repo you own - with your VS Code setup carried across. The download itself is a couple of clicks, but unlike installing an extension or a CLI, installing Cursor means replacing your editor, so the half hour you spend here has real substance: carrying your 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 (Cursor’s chat panel for delegating tasks) and Tab (inline completion) - 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; if you don’t see it, the settings route below always works, and you can run it any time afterward.

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 (as of September 2026; migration guide), where an Import button does the transfer in a single step. What arrives lands in Cursor’s own user folder - on macOS, ~/Library/Application Support/Cursor/User/settings.json, the same shape as VS Code’s but inside Cursor’s application-support home - because Cursor, being its own application, keeps its own user state. Your user settings, keybindings, and theme do not flow there by themselves; the import is what carries them.

One inheritance needs no import at all, because it never lived in an app folder: project files. A .vscode/settings.json checked into your repo is read exactly as VS Code would read it, because it sits in the project, not in either editor’s user state. Clone the repo, open it in Cursor, and the project’s settings apply whether or not you ever run the import.

So when you open your repo in Cursor for the first time after the import, the editor already looks like the one you closed: your theme, your tab width, your format-on-save, your shortcuts - carried across by the import, on top of whatever the project itself carries.

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 (Cursor’s extensions doc, as of September 2026). 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 - the packaged extension file, which Cursor reads the same way the marketplace would have handed it over. How you install one is the next paragraph’s job.

Make the gap concrete. The case you’ll actually hit first: an extension you depend on is marketplace-only - published to Microsoft’s registry, never shipped to Open VSX - so it quietly fails to appear after the import. The second case: internal tooling, like a .vsix budgetcli’s maintainers might build for a private linter, which sits on no public registry at all. Both take the same fallback. Download the .vsix from a source you trust, 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. The reason to learn this path 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 the plan shape is worth a glance now so the choice there is informed rather than rushed: a free tier (named Hobby on older plans) that is enough to ship one reviewed change, paid individual tiers, and Teams/Enterprise layers with admin controls (as of October 2026, cursor.com/pricing). The next lesson walks the full tier list and what each one meters. 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 your repo, 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 by that same import, your project’s own .vscode/ applying as it always did. 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.