Migrating to Cursor from VS Code

The import lives in Cursor Settings, not in a first-run wizard, so you can run it whenever you like, including after you have already been using Cursor for a while. Three steps get you there.

1. 1Open Cursor Settings: Mac press Cmd + Shift + J; Windows/Linux press Ctrl + Shift + J.
2. 2Go to General → Account.
3. 3Under VS Code Import, click the Import button.

That single action brings over your extensions, themes, settings and keybindings. Extensions and keybindings are the two that need checking afterwards, which is why most of this page is about them.

There is an ordering question here that the help page does not settle. It says what the import brings over. It says nothing about choices you have already made inside Cursor, so if you spent an evening on your theme and your font and then click Import, I cannot tell you whether your work survives or gets replaced, and guessing at it seemed worse than saying so. Run the import on a fresh install, before you customize anything, and the question never comes up.

That advice is no use to you if you have been in Cursor for months already. Run the import anyway. Whatever it might overwrite, you can put back in an evening, and getting your whole old keymap in one click is worth that evening.

Many of them, though not all, and the registry is the reason. Cursor installs extensions from the Open VSX registry rather than the VS Code Marketplace. Many popular extensions are there. Anything niche may not be listed at all, and what is listed may not work exactly the same way. Our install guide covers how to check your own list.

The problem going the other way is what the import brings that you did not want. One click means all of it, including whatever else was completing your code in VS Code. Cursor's troubleshooting page is blunt about which extensions cause trouble. Extensions that ship their own AI completions or grab keyboard shortcuts are the ones it names, and other AI coding assistants are called out as the main culprits. Having two or three of those in your VS Code today is the one setup where I would not click Import first.

If Tab goes quiet on your first morning in Cursor, or a shortcut does nothing at all, start in the Extensions panel (Cmd/Ctrl + Shift + X) and disable the other assistant before you change anything else. If the panel will not open, check whether you are in the Agents WindowCursor's surface listing your agent runs; open a run to read its diff and search transcripts from the command palette. Press Enter for the full definition. rather than the IDE. Run Open IDE from the command palette first. For a conflict you cannot place, the elimination routine in our troubleshooting guide finds it faster than reading extension names.

Mostly they do. Cursor ships VS Code's default shortcuts, so the keys you already press keep doing what they did, and your custom keybindings come across with the import, in the same bundle as your settings and themes.

What Cursor adds sits on top of that rather than in place of it. Cmd/Ctrl + I or Cmd/Ctrl + L opens the AI side panel, Cmd/Ctrl + K makes an inline edit, Cmd/Ctrl + . opens the mode menu, Shift + Tab rotates through the agent modes, and Cmd/Ctrl + / loops between models. The one that catches VS Code hands is Cmd + K, which used to be the leader for two-step chords and now belongs to inline edit, so those chords moved to a different leader. Our keybindings.json guide has the mapping.

The instinct when a chord stops working is to open your old keybindings.json and paste it across. I would skip that. Imported entries have turned up with when fields reading (arbitrary function), a placeholder left where a condition could not be carried over, and those bindings never fire however correct the key looks. Delete them and rebind through the Keyboard Shortcuts screen instead: Cmd + R then Cmd + S on Mac, Ctrl + R then Ctrl + S on Windows and Linux.

One click, for almost everyone. Exporting a profile from VS Code and importing it by hand is the route Cursor points at when you want more control over what moves, and its VS Code migration guide has those steps.

More control is the whole justification the help page offers, and it does not spell out what the control buys you. The manual route pays off, as far as I can tell, in one situation: you already know something in your VS Code setup should not follow you across. A dead extension you never uninstalled, or the second AI assistant from the section above. Without a reason that specific, take the click.

On your own machine, none of this is worth more than a minute of thought. Across a team of forty it changes shape, though not because the click is any harder. The extension question gets asked forty times instead of once, and the people who ask it after they have already switched are the ones most likely to give up on the move. Do the lookup once, before a rollout date exists, and write the answer down as two columns: what your build and lint steps depend on, and what to use where Open VSX has nothing.

Yes. Cursor and VS Code install as separate applications and both can work on the same projects, so nothing forces a decision on day one.

It starts to cost you something when that runs for months. The import is an action you run, and nothing in Cursor's help page describes it as an ongoing sync, so I would not treat it as one. Keep editing settings in both editors and the two drift, which is how a formatter ends up behaving differently in two windows on the same file and you lose an afternoon comparing config.

The usual worry about a migration is rollback, and there is nothing here to roll back, which quietly moves the risk somewhere else. What goes wrong is rarely a switch that fails. It is a switch that never finishes, and you spend six months with both editors open, doing half your configuration in each. Moving one real project across whole, and refusing to open that project in VS Code, tends to settle it inside a week.