How to Install Cursor (Mac, Windows & Linux)

Download the build for your operating system from cursor.com, run the installer, then let Cursor import your VS Code setup the first time it launches. The five steps below take you from a download to your first prompt in a few minutes.

1. 1Go to cursor.com and download the build for macOS, Windows or Linux.
2. 2Run the installer (macOS: drag to Applications; Windows: run the .exe; Linux: the AppImage/.deb).
3. 3Launch Cursor and import from VS Code when prompted - extensions, settings and keybindings carry over.
4. 4Sign in to sync settings and usage (optional, but recommended).
5. 5Open a project folder and start with the chat (Ask) or Tab autocomplete.

Install, import, sign in, open a folder. The last step is, I think, where a first session usually goes wrong, because people open their biggest repo and ask a question straight away. Cursor starts building its semantic index the moment you open a workspace, and semantic search only becomes available once that index reaches 80%. A weak first answer on a fresh clone is usually a half-built index rather than a weak model, so give it a minute and ask the same question again.

On your own machine, the direct download from cursor.com/download is the whole story. Cursor auto-updates on each launch after that, so the version you are running looks after itself.

If your employer owns the laptop, none of that is your decision. Managed fleets get Cursor pushed out through MDM with the build and the update policy already set, and honestly that is the easier position to be in.

Mostly, yes. Cursor is a fork of VS Code, so your themes, keybindings and settings.json come across in one click, and Cursor ships VS Code's default shortcuts, so the keys you already press keep doing what they did. The import also lives in Cursor Settings under General → Account, so you can run it whenever you like. Skipping the first-run prompt costs you nothing.

Extensions are the exception.

Cursor installs them from the Open VSX registry rather than the VS Code Marketplace, so what carries over depends on what has been published there. Many popular extensions have been, others have not, and a few of the ones that are listed behave a little differently. It is not the sort of thing you check at install time. You find out later, when you go looking for the linter your team standardized on and it is not there.

So make a short list before you switch, the extensions you would miss, and check them against Open VSX first. Actually, that is the wrong list. Make it the ones your workflow depends on, whether you are fond of them or not. Losing a theme costs you an afternoon of mild irritation. Losing a debugger is a reason to go back, and that is the one you want to know about in advance.

No need to commit either way. Cursor and VS Code are separate applications and can sit open on the same project at the same time, so install Cursor, run the import, and leave VS Code where it is until you stop opening it. Most people stop, though that is a guess from the handful I have watched rather than anything measured.

You can use Cursor signed out with limits, and signing in is what syncs your settings and enables paid usage and team features. The Free (Hobby) tier is $0 and includes limited model usage plus the core editor, which is enough to find out whether you like working this way and short of what a working day asks for.

Signing in is also where a work machine and a personal account quietly diverge, and the identity you pick is the part I would slow down for. If your company has a Cursor team, sign in with the work identity the first time rather than the account you already had, because your settings and your privacy posture both follow the account. Enterprise admins can set an allowed team ID specifically to stop people using personal accounts that may not have Privacy ModeCursor's setting that guarantees code data is not used for training by Cursor or its model providers, and that an admin can enforce org-wide; data-retention terms are a separate, contractual layer. Press Enter for the full definition. enabled, which tells you how ordinary the mistake is.

Privacy ModeCursor's setting that guarantees code data is not used for training by Cursor or its model providers, and that an admin can enforce org-wide; data-retention terms are a separate, contractual layer. Press Enter for the full definition. is available on every tier, it is on by default for Enterprise teams, and admins can enforce it org-wide so members cannot switch it off. What it guarantees is that your code is not used for training, by Cursor or by the model providers. It does not mean the code stays on your machine, since it is still sent to providers to generate a response. If that distinction is going to matter to someone in your security team, settle it before install day rather than after.

The rest of the account screen can wait. Sign in, check which team you landed in, open a folder. Everything after that is a settings question, and settings questions keep.

Set a spend cap first if you are on a paid plan, then write one rules file, then learn the shortcuts. The list below is in that order. Only the first of the three can cost you anything.

• Pick your models and set a usage-based spend cap if you're on a paid plan.
• Add a .cursor/rules/ file with your conventions so the AI follows them from day one.
• Learn the core shortcuts (Tab, inline edit, chat, agent).

Usage-based pricing is opt-in, so nothing bills you by accident. The moment you do opt in to keep working past your included allowance, you are paying model API rates on whatever you run, and a long agent session spends quicker than it feels like it should. The cap is one number in Settings. Set it while you are already in there, because it is probably the only item on this list you would regret leaving for later.

Rules live under .cursor/rules/ as .mdc files, they load on their own when they apply, and every rule that applies spends context on that request. So the usual advice, write your conventions down, is half an answer at best. The half that decides whether the file earns its context is which conventions, and the ones worth writing are the ones you have already watched the agent get wrong.

As for the shortcuts, leave them. VS Code's defaults are already in there, so most of your muscle memory works on day one, and the Cursor-specific keys arrive when you need them.

Two failures cover most of what goes wrong on day one, as far as I can tell. One is a corporate proxy that will not carry Cursor's traffic. The other is an agent that appears unable to see files sitting in the folder you just opened.

Proxies first, then. Most corporate proxies work with no configuration at all, and the failure that does show up is a network blocking HTTP/2, with Zscaler as the documented example. What surfaces is slow connections or auth failures, nothing that says the word proxy, which is probably why the first instinct is to reinstall. The setting you want is HTTP Compatibility Mode under Cursor Settings → Network, which falls back to HTTP/1.1.

The "it cannot see my file" report comes down to the index. Cursor excludes anything matched by .gitignore or .cursorignore, along with binaries and very large files, and semantic search does not switch on until indexing reaches 80%. So check the ignore files first, give a large repo a minute, and attach the file with an @ mention if you need an answer right now. Which works. It is just not the fix.