VS Code Extensions in Cursor: 12 Steps, 45 Min [2026]

Cursor is built on top of VS Code’s source, which is why it can read a VS Code configuration file without any conversion step. But the two editors still keep separate extension installs, separate registries, and a settings importer that, as of the current 3.x builds, only moves part of your setup. If you have ever opened Cursor for the first time and found your theme in place but your linter, your Docker tooling, or your favorite snippet pack missing, this guide fixes that gap. It walks through installing VS Code extensions in Cursor, working around the known import bug, and keeping both editors usable side by side without breaking either one.

This is a step-by-step build: prerequisites, exact commands, the specific forum-reported bug that blocks automatic extension import, and a full troubleshooting section for when an extension installs but refuses to activate. By the end you will have a working hybrid setup where VS Code and Cursor share the same keybindings, similar settings, and the same core extension list, while Cursor’s AI layer (Composer, Agent, Tab) stays fully separate from anything Microsoft ships.

None of this is a one-time inconvenience, either. Developers moving between the two editors run into it every time they set up a new machine, onboard a new laptop after a hardware refresh, or bring a teammate onto Cursor for the first time. The registry gap and the import bug are stable features of how Cursor currently works, not a transient glitch that a patch will quietly erase next week — so it’s worth building a repeatable process once rather than re-solving it by trial and error every time.

·

Google · Preferred Sources

Don't miss new tech stories on Google

Add Tech Insider once in the Google app and our stories appear in your news suggestions.

Add Now

Why VS Code and Cursor extensions don’t just sync automatically

Cursor is a direct fork of VS Code, built by Anysphere. It reads VS Code’s settings.json and keybindings.json formats natively, and it supports the same .vsix extension package format and the same extension API that VS Code uses. That part is genuinely compatible: an extension packaged for VS Code will generally install and run in Cursor without modification, because the underlying extension host is the same.

The catch is the registry. VS Code pulls extensions from Microsoft’s official Visual Studio Code Marketplace. Cursor, for licensing reasons tied to Microsoft’s marketplace terms, uses Open VSX instead — an open-source registry that mirrors much of the VS Code Marketplace but not all of it. A handful of Microsoft-published extensions, most notably some remote-development and native debugging tools, are either missing from Open VSX or published there with delayed updates. That single registry difference is the root cause of almost every “why can’t I find this extension in Cursor” question in the Cursor community forum.

On top of the registry gap, Cursor’s built-in VS Code Import flow has a known limitation. A thread on the Cursor community forum reports that the VS Code Import button reliably brings over settings and keybindings but does not import extensions in current builds, and a moderator reply in a related thread describes this gap as “expected right now.” That means anyone relying on the one-click import is going to open Cursor, see their color theme and shortcuts intact, and then find an empty extensions panel. This guide treats that as the default case and walks through the manual extension install path that actually works today.

Open VSX vs the VS Code Marketplace: what’s actually different

It’s worth understanding the two registries before you start moving extensions, because the difference explains almost every surprise you’ll hit later in this guide. The VS Code Marketplace is Microsoft-operated and closed-source; its terms of service restrict which products are allowed to query it programmatically, which is why forks like Cursor, VSCodium, and Google’s Project IDX-adjacent tools can’t simply point their extensions panel at it. Open VSX is a community-run, Eclipse Foundation-hosted alternative built specifically so VS Code forks have a legal, functioning extension registry of their own.

In practice, most publishers dual-publish to both registries, since doing so is a single extra step in their CI pipeline. The gap shows up mainly with large, well-resourced publishers who see little incentive to maintain a second distribution channel — Microsoft’s own first-party tooling being the clearest example. The table below summarizes the practical differences you’ll run into during this migration.

Aspect	VS Code Marketplace	Open VSX
Operator	Microsoft	Eclipse Foundation, community-run
Used by	VS Code, Visual Studio	Cursor, VSCodium, Theia, Gitpod, most other forks
License terms	Restricts third-party client access	Open, no client restriction
Coverage vs Marketplace	100% (it’s the source)	Large majority of popular extensions, with some first-party Microsoft gaps
Publish process for extension authors	Manual or CI-based publish to Marketplace	Separate publish step, often automated in the same pipeline
Typical update lag	None (source registry)	Usually same-day to a few days behind, depending on publisher automation

Prerequisites and exact versions

Confirm these before starting. Version drift between the two editors is the single most common cause of extensions that install but refuse to activate.

Requirement	Version / detail	Why it matters
Cursor	3.20 (current downloads-page release) or later	Extension API level and Import flow behavior differ across 3.x builds
VS Code	Any recent stable build with Settings Sync enabled	Source of the settings.json and keybindings.json you’re porting over
VS Code Extension API (Cursor)	1.105.1 or later, shown in Cursor’s About dialog	Extensions built against a newer API can fail silently on older Cursor builds
Operating system	Windows 10/11, macOS 13+, or Ubuntu 22.04+	Extension binaries with native modules are OS- and arch-specific
Node.js (for building/debugging extensions)	LTS 20.x or later	Needed only if you’re packaging or testing a custom .vsix
Disk space	~2 GB free per editor	Each editor keeps its own extension cache; nothing is shared on disk

You do not need a paid Cursor plan to follow this tutorial. The free Hobby tier gives full access to the editor, extension installs, and Composer with limited Agent requests — the pricing tiers only change how much of Cursor’s AI features you get, not extension compatibility. If you plan to lean on Cursor’s Agent mode heavily afterward, the paid tiers on Cursor’s pricing page break down as: Pro at $20/month (or roughly $16/month billed annually) with extended Agent limits and frontier model access, Pro+ at about $60/month with roughly 3x the Pro Agent allowance, Ultra at around $200/month with 20x Pro’s limits, and Business/Teams at $40 per user per month for centralized billing and SSO. None of that affects the steps below.

Budget roughly 45 to 90 minutes for the full walkthrough on a typical developer machine with 15-30 installed extensions. The table below breaks down where the time actually goes, so you can skip ahead if part of this doesn’t apply to your setup — for instance, if you have no Marketplace-exclusive extensions, you can skip Step 6 entirely.

Phase	Steps	Typical time
Export and audit	1-2	5-10 minutes
Settings and keybindings import	3	2-5 minutes
Extension cross-check and bulk install	4-5	10-20 minutes
Manual sideloading (if needed)	6	0-20 minutes, depends on gap count
Settings and keybinding verification	7-8	10-15 minutes
AI configuration and sync strategy	9-10	10-15 minutes
Testing and workflow decision	11-12	10-15 minutes

Step 1: Check what’s already installed in VS Code

Before touching Cursor, get a clean list of what you’re actually running in VS Code. Open a terminal and run:

code --list-extensions --show-versions > vscode-extensions.txt
cat vscode-extensions.txt

This dumps every installed extension with its exact version to a text file. You’ll use this list twice: once to cross-check availability on Open VSX, and once at the end to confirm nothing got missed. If code isn’t recognized, you haven’t added VS Code to your PATH — on Windows, reinstall with the “Add to PATH” checkbox ticked; on macOS, run Shell Command: Install ‘code’ command in PATH from the Command Palette first.

Step 2: Locate your VS Code settings and keybindings files

These are plain JSON files Cursor can read directly. Find them here:

OS	settings.json path	keybindings.json path
Windows	%APPDATA%\Code\User\settings.json	%APPDATA%\Code\User\keybindings.json
macOS	~/Library/Application Support/Code/User/settings.json	~/Library/Application Support/Code/User/keybindings.json
Linux	~/.config/Code/User/settings.json	~/.config/Code/User/keybindings.json

Open both files and skim them. If you use VS Code’s Settings Sync, these will already be current. If you’ve never enabled sync, open the Command Palette in VS Code and run Preferences: Open User Settings (JSON) to generate the file if it doesn’t exist yet.

Step 3: Run Cursor’s built-in VS Code Import (for settings and keybindings only)

Open Cursor and go to Settings — Cmd+Shift+J on macOS, Ctrl+Shift+J on Windows/Linux. Navigate to General, then Account, and find VS Code Import. Click Import.

This step reliably brings over your theme, editor preferences, and keybindings. Do not expect it to bring your extensions — per the forum thread cited above, that part of the import is not implemented in current builds. Treat this step as “settings and shortcuts only” and move on to manual extension installation next.

Step 4: Cross-check your extension list against Open VSX

Open the file from Step 1 and check each extension ID against Open VSX before assuming it’ll install cleanly in Cursor. You can query the registry’s API directly instead of clicking through the website for each one:

# Replace PUBLISHER.EXTENSION-NAME with an ID from your list, e.g. esbenp.prettier-vscode
curl -s "https://open-vsx.org/api/PUBLISHER/EXTENSION-NAME" | python3 -m json.tool

A successful response returns JSON with version, downloadCount, and files fields. A 404 means that extension isn’t published to Open VSX at all — this is common for a small number of Microsoft first-party extensions, including some remote-development and C/C++ debugging tools that Microsoft licenses exclusively to its own Marketplace. For those, you’ll need the manual .vsix sideload method in Step 6.

Step 5: Bulk-install available extensions from inside Cursor

For anything that did resolve on Open VSX, install it the same way you would in VS Code — the Extensions panel and Command Palette behave identically. Open the Extensions view (Ctrl+Shift+X / Cmd+Shift+X) and search by name, or script it from a terminal for speed:

# Cursor exposes a CLI binary named "cursor" once installed
while read -r ext; do
  id=$(echo "$ext" | cut -d'@' -f1)
  cursor --install-extension "$id"
done < vscode-extensions.txt

If the cursor command isn't found, open Cursor's Command Palette and run Shell Command: Install 'cursor' command in PATH, then reopen your terminal. This loop attempts every extension ID from your VS Code list; entries that don't exist on Open VSX will fail with a clear "extension not found" message rather than hanging, so you can scan the output for failures and handle those individually.

Step 6: Sideload the extensions Open VSX doesn't have

For the handful of extensions missing from Open VSX, you can still get the .vsix file directly and install it manually — this works because Cursor's extension host reads the same package format VS Code does, regardless of which registry it came from.

Download the .vsix from the Visual Studio Code Marketplace page for that extension (use the "Download Extension" link found in the page's sidebar under "Resources"), then install it with:

cursor --install-extension /path/to/downloaded-extension.vsix

Or, from inside the Cursor UI: open the Extensions panel, click the "..." menu in the top-right corner, choose "Install from VSIX...", and point it at the downloaded file. This is the same three-dot menu VS Code uses, so if you've sideloaded an extension in VS Code before, the flow is identical.

A word on sideloading safety: only download .vsix files from the extension's official Marketplace listing, never from a third-party mirror or a link shared in a forum post. Sideloaded extensions bypass the registry's own scanning step, so verify the publisher name matches exactly what you'd expect (check for lookalike publisher IDs — a common supply-chain trick is publishing a near-identical extension name under a slightly different publisher string) before running "Install from VSIX." This matters more in Cursor than in VS Code precisely because sideloading is the fallback path for every Marketplace-exclusive extension you'll need here, not an edge case.

Step 7: Port over language and formatter settings that reference extension IDs

Some settings in your settings.json reference specific extension IDs — default formatters, linter configs, language server paths. Even after the extension installs correctly, these settings will silently do nothing if the referenced extension ID doesn't match. Open Cursor's settings.json (Ctrl+Shift+P / Cmd+Shift+P, then Preferences: Open User Settings (JSON)) and check entries like this:

{
  "editor.defaultFormatter": "esbenp.prettier-vscode",
  "eslint.validate": ["javascript", "typescript"],
  "python.defaultInterpreterPath": "/usr/bin/python3.12",
  "editor.formatOnSave": true
}

Since Cursor and VS Code use the same extension IDs (the publisher.name format is preserved on Open VSX), these settings usually copy over verbatim without edits. The one exception is any setting that points to an absolute install path for an extension binary (rare, but seen with some C++ toolchain extensions) — those need to be updated to Cursor's separate extension storage directory.

Step 8: Verify keybinding conflicts introduced by Cursor's AI features

Cursor shares VS Code's default shortcuts for navigation and editing (Ctrl+P to open files, Ctrl+Shift+P for the Command Palette, Ctrl+` for terminal). But it adds its own bindings for Composer, Tab completion acceptance, and Agent chat, and some of these can collide with custom keybindings you set up for extensions in VS Code — most commonly Tab-triggered snippet extensions competing with Cursor's Tab-to-accept-suggestion behavior.

Open Cursor's Keyboard Shortcuts editor (Ctrl+K Ctrl+S) and search for anything bound to Tab, Ctrl+K, or Ctrl+L, since those three are Cursor's primary AI shortcuts (Tab-complete, inline edit, and Chat, respectively). If an old extension keybinding you imported in Step 3 uses one of these, rebind the extension's shortcut rather than disabling Cursor's AI binding — you'll get more value out of Cursor by keeping its native shortcuts intact.

Step 9: Configure Cursor's AI layer without touching your ported extensions

With extensions and settings in place, set up the parts of Cursor that have no VS Code equivalent: Composer (multi-file AI edits), Agent mode, and Cursor Rules (project-specific instructions for the AI). None of this interacts with your extension list, so it's safe to configure independently.

Create a .cursor/rules directory at your project root and add a rules file to scope AI behavior to your stack — for example, a rule telling Cursor's Agent to always use your project's existing linter config rather than proposing its own formatting:

mkdir -p .cursor/rules
cat > .cursor/rules/project.mdc << 'EOF'
---
description: Project conventions for AI-assisted edits
alwaysApply: true
---
- Follow the existing ESLint and Prettier config in this repo; do not propose new formatting rules.
- Match the TypeScript strictness settings already defined in tsconfig.json.
- Prefer editing existing files over creating new abstractions.
EOF

This is where the hybrid workflow pays off: your linter and formatter extensions enforce style automatically, while Cursor's Agent respects those same rules instead of fighting them.

It's worth writing more than one rules file if your project spans multiple stacks — a monorepo with a Python backend and a React frontend benefits from separate rule files scoped by glob pattern, so the Agent doesn't apply frontend linting conventions when it's editing backend code. Cursor supports scoping a rules file to specific paths using a globs field in the frontmatter, which keeps a single large ruleset from becoming unmanageable as the project grows.

Step 10: Set up a shared settings sync strategy between both editors

Because Cursor's Import only runs a one-time copy, any setting you change later in VS Code won't propagate to Cursor automatically, and vice versa. Two practical approaches:

• Keep a single settings.json in a dotfiles repo and symlink both editors' User settings folders to it. This keeps them perfectly in sync but risks Cursor-specific settings leaking into VS Code (harmless, since VS Code just ignores keys it doesn't recognize).
• Treat VS Code as the source of truth and re-run the Import step in Cursor periodically (monthly, or after any major settings change) — simpler to manage, but introduces drift between imports.

For most solo developers, the symlink approach is worth the ten minutes it takes to set up. Here's the macOS/Linux version:

mkdir -p ~/dotfiles/editor
cp ~/.config/Code/User/settings.json ~/dotfiles/editor/settings.json
rm ~/.config/Code/User/settings.json
ln -s ~/dotfiles/editor/settings.json ~/.config/Code/User/settings.json
rm ~/.config/Cursor/User/settings.json
ln -s ~/dotfiles/editor/settings.json ~/.config/Cursor/User/settings.json

Back up both original files before running this — a bad symlink target will make both editors fall back to defaults, and you don't want to reconstruct your settings from memory.

Step 11: Test the full setup with a real project

Open an existing project in Cursor and check these four things in order: the correct theme loads, your linter flags an intentional error (add one temporarily to confirm), format-on-save fires with your usual formatter, and Cursor's Tab completion still works for AI suggestions without your snippet extension swallowing the keystroke. If all four pass, the migration is functionally complete.

# Quick sanity check: list installed extensions in Cursor and diff against your VS Code export
cursor --list-extensions --show-versions > cursor-extensions.txt
diff vscode-extensions.txt cursor-extensions.txt

Expected output is a short diff showing only version-number mismatches (Open VSX sometimes lags a patch version or two behind the VS Code Marketplace) rather than entire extensions missing. If large chunks of your list are absent from cursor-extensions.txt, go back to Step 4 and re-check those specific IDs against Open VSX.

Step 12: Decide which editor handles which task going forward

Once both editors carry the same extensions, the practical question becomes when to actually switch between them. A reasonable split that most hybrid users settle on: stay in Cursor for anything involving AI-assisted multi-file refactors, Agent-driven bug fixes, or fast Tab-completion heavy typing, and drop back to plain VS Code for tasks where an extension not yet on Open VSX is required, for remote-SSH development into environments where only VS Code is approved, or when working in a locked-down corporate environment where Cursor's telemetry and cloud-agent calls aren't cleared by IT.

Keeping both installed costs about 2 GB of disk per editor plus separate extension caches — a small price for not having to choose one tool permanently, especially while Cursor's registry gap with Open VSX still exists.

Handling monorepos and multi-root workspaces

If your day-to-day work spans a multi-root workspace or a large monorepo, extension behavior can differ subtly between VS Code and Cursor even after a clean migration, because workspace-level settings (as opposed to user-level settings) live in a separate .vscode/settings.json file inside the repo itself rather than in your user profile. Cursor reads this file the same way VS Code does, so workspace-scoped formatter and linter overrides carry over without any extra work — but it's worth explicitly checking that any workspace-level extension recommendations file (.vscode/extensions.json) doesn't list Marketplace-exclusive IDs that will fail to resolve when a teammate opens the project in Cursor for the first time.

For monorepos with multiple language stacks, it's worth testing the full migration against the specific sub-project you use most, rather than assuming a clean result from one folder means every folder in the repo behaves the same way. Language server extensions in particular can behave differently depending on how deep in the folder tree they're triggered.

Rolling this out across a team

If you're introducing Cursor to a team that's standardized on VS Code, don't rely on each engineer independently rediscovering the Open VSX gap. Commit the vscode-extensions.txt export and the sync-editors.sh script from this guide into the repo's onboarding documentation, along with a short list of any Marketplace-exclusive extensions your team specifically depends on (remote-container tooling is the most common one) so new Cursor users know upfront which extensions require the manual Step 6 sideload rather than discovering it through a confusing missing-feature bug report.

Cursor's Business tier adds centralized admin controls that are worth using once more than a couple of engineers are on the platform: it lets an admin push a shared Cursor Rules baseline and manage seats from one dashboard, instead of every developer configuring .cursor/rules independently and slowly drifting out of sync with each other.

Common pitfalls when running VS Code extensions in Cursor

• Assuming the VS Code Import button moves extensions. It currently only moves settings and keybindings, according to reports on Cursor's own community forum. Budget time for manual installs.
• Installing a .vsix built for a much newer VS Code Extension API than Cursor currently supports. Check Cursor's About dialog for its current API level (1.105.1 in recent builds) before sideloading anything unusual.
• Forgetting that extensions are per-editor, not shared. Installing something in VS Code today does not make it appear in Cursor tomorrow, and there's no background sync process watching for this.
• Symlinking settings.json without backing up the originals first. A typo in the symlink target silently resets both editors to default settings with no error dialog.
• Letting a snippet extension's Tab-trigger fight Cursor's Tab-to-accept-AI-suggestion binding. This shows up as "my snippets stopped expanding" and is a keybinding conflict, not a broken extension.
• Expecting 100% Open VSX parity with the VS Code Marketplace. A small set of first-party Microsoft extensions, notably some remote-development and native debugging tools, are marketplace-exclusive by license, not by oversight.
• Running the bulk-install loop against an extension list from a different OS. An extensions file exported on Windows can reference native-module extensions that don't have a Linux or macOS build; the install will fail per-extension rather than breaking the loop.

Output examples: what a clean migration looks like

A successful Step 5 bulk-install run for a typical 20-extension list looks like this in the terminal:

Installing extensions...
Extension 'esbenp.prettier-vscode' v11.0.0 was successfully installed.
Extension 'dbaeumer.vscode-eslint' v3.0.10 was successfully installed.
Extension 'ms-python.python' v2026.8.0 was successfully installed.
Extension 'ms-vscode-remote.remote-ssh' not found on Open VSX registry.
Extension 'bradlc.vscode-tailwindcss' v0.12.20 was successfully installed.
...
17 of 20 extensions installed. 3 require manual .vsix sideload (see Step 6).

The Step 11 diff output for a fully matched setup should be short — typically just patch-version differences, not missing extension IDs:

2c2
< [email protected]
---
> [email protected]

Troubleshooting: 8+ issues and fixes

1. "cursor" command not found in terminal. Open the Command Palette in Cursor and run Shell Command: Install 'cursor' command in PATH, then restart your terminal session — this mirrors the identical VS Code fix.

2. Extension installs but the icon stays greyed out. This usually means the extension is waiting on a dependency extension that failed to install. Check the Extensions panel for a "requires" note and install the dependency manually first.

3. Extension ID returns 404 from the Open VSX API. Confirm you're using the exact publisher.name format from your VS Code export (case-sensitive). If it still 404s, the extension genuinely isn't published to Open VSX — use the Step 6 sideload path.

4. Formatter runs in VS Code but not in Cursor, even though the extension shows as installed. Check editor.defaultFormatter in Cursor's settings.json — a stale value pointing at an extension ID that changed publishers will fail silently rather than throwing an error.

5. Keybinding no longer works after import. Open Keyboard Shortcuts (Ctrl+K Ctrl+S), search the command name, and check for a Cursor-native entry overriding your imported binding — Cursor's AI-specific bindings take precedence on Tab, Ctrl+K, and Ctrl+L by default.

6. .vsix sideload fails with an "incompatible" error. The extension's declared engines.vscode version in its manifest is newer than Cursor's current Extension API level. Downgrade to an older .vsix release from the Marketplace's version history, or wait for Cursor's next build.

7. Settings symlink breaks after a Cursor auto-update. Some Cursor updates recreate the User settings folder rather than editing the file in place, which can silently replace your symlink with a fresh regular file. Re-run the symlink command from Step 10 after major version updates.

8. Remote-SSH or Dev Containers extension missing entirely. Microsoft's official remote-development extensions are Marketplace-exclusive and not mirrored to Open VSX. There is no supported sideload workaround for these specific extensions due to license restrictions — for remote development, use VS Code directly rather than trying to force it into Cursor.

9. Bulk-install script hangs on one extension. Add a timeout to the loop (timeout 30 cursor --install-extension "$id") so a single unresponsive download doesn't block the rest of the list.

10. Two different Prettier or ESLint configs conflict between editors. If you edited formatter rules in one editor's settings after the initial import, they've now diverged. Pick one editor as the source of truth and re-sync using the Step 10 symlink method.

Advanced tips for a long-term hybrid setup

Once the base setup is stable, a few refinements make daily use smoother. Pin your dotfiles-based settings.json to a private Git repo so a machine reinstall takes minutes instead of redoing this entire guide. Add a .gitignore entry for .cursor/ in shared team repos unless you deliberately want to commit rules files for teammates — Cursor Rules are genuinely useful to share across a team, but not every repo wants an opinionated AI-behavior file checked in.

For teams standardizing on Cursor, Business tier at $40 per user per month adds centralized admin controls and SSO, which matters once you're managing extension policy and Cursor Rules across more than a handful of engineers rather than just your own machine.

If you rely on an extension that's Marketplace-exclusive and central to your workflow (remote containers being the most common case), it's worth periodically re-checking Open VSX rather than assuming it'll never appear — the registry has added previously-missing extensions over time as publishers dual-publish.

One more habit worth building: after a large refactor of your extension list in one editor (removing a batch of unused language packs, say), re-run the Step 1 export and diff it against the previous version before propagating the change to the other editor. This catches accidental removals — an extension you use rarely but still need — before they silently disappear from your second editor too.

Cleaning up after the migration

Once you've confirmed the hybrid setup works, resist the urge to immediately uninstall extensions from whichever editor you use less. Keep both installations current for at least a few weeks of regular use, since some issues (a formatter that only triggers on a specific file type, a snippet you use once a month) won't surface until you hit the exact workflow that depends on them. After that trial period, if you've settled on Cursor as your primary editor, it's safe to trim VS Code down to a minimal set — keep it installed for the Marketplace-exclusive extensions from Step 6 and for any remote-development work, and remove the rest to cut down on background update noise and disk usage.

Do the trim from the terminal rather than clicking through the UI extension-by-extension, since it's faster and leaves you with a clean audit trail of exactly what was removed:

# Example: remove three extensions no longer needed in VS Code
code --uninstall-extension ms-vscode.vscode-typescript-tslint-plugin
code --uninstall-extension formulahendry.auto-close-tag
code --uninstall-extension christian-kohler.path-intellisense

Complete working project: a portable setup script

Combining every step above into one reusable script gives you a repeatable migration for any new machine. Save this as sync-editors.sh:

#!/usr/bin/env bash
set -euo pipefail

echo "Step 1: Exporting VS Code extension list..."
code --list-extensions --show-versions > vscode-extensions.txt

echo "Step 2: Installing extensions in Cursor (timeout 30s each)..."
FAILED=()
while read -r ext; do
  id=$(echo "$ext" | cut -d'@' -f1)
  if ! timeout 30 cursor --install-extension "$id" 2>/dev/null; then
    FAILED+=("$id")
  fi
done < vscode-extensions.txt

echo "Step 3: Diffing final extension lists..."
cursor --list-extensions --show-versions > cursor-extensions.txt
diff vscode-extensions.txt cursor-extensions.txt || true

if [ ${#FAILED[@]} -gt 0 ]; then
  echo ""
  echo "The following extensions were not found on Open VSX and need manual .vsix sideload:"
  printf '  %s\n' "${FAILED[@]}"
fi

echo ""
echo "Done. Settings and keybindings still require the in-app VS Code Import (Settings > General > Account)."

Run it with bash sync-editors.sh after any fresh Cursor install. It handles the bulk of the extension migration automatically and flags exactly which extensions need the manual Step 6 sideload, so you're never guessing which ones failed silently.

Frequently asked questions

Does Cursor automatically install my VS Code extensions?
No. Cursor's VS Code Import currently transfers settings and keybindings only — extensions must be installed manually, either through the bulk-install method in Step 5 or by sideloading a .vsix for anything missing from Open VSX.

Why does Cursor use Open VSX instead of the VS Code Marketplace?
Cursor's own documentation states it uses the Open VSX registry rather than Microsoft's Marketplace. Microsoft's Marketplace terms restrict which products can query it directly, so VS Code forks generally rely on the open-source Open VSX registry instead.

Will an extension built for VS Code work in Cursor without changes?
In almost all cases, yes — same .vsix package format, same extension API. The exceptions are extensions with a hard dependency on a VS Code Marketplace-only feature or one built against a newer API level than Cursor's current build supports.

Can I run VS Code and Cursor on the same project at the same time?
Yes, they use separate lock files and don't conflict at the process level, though you should avoid having both auto-format the same file on save simultaneously to prevent redundant writes.

Do I need a paid Cursor plan to install extensions?
No. Extension installation, the Extensions panel, and Open VSX access are all available on Cursor's free Hobby tier. Paid tiers (Pro at $20/month, Pro+ at about $60/month, Ultra at around $200/month) only affect Agent request limits and frontier-model access, not extension compatibility.

What happens to my keybindings if I use both editors regularly?
Since Cursor shares VS Code's default shortcut scheme and the Import step copies your custom keybindings.json, day-to-day navigation stays consistent. Watch for conflicts specifically around Tab, Ctrl+K, and Ctrl+L, which Cursor reserves for its AI features.

Why did an extension I sideloaded fail to activate?
The most common cause is an API version mismatch — the .vsix was built against a newer VS Code Extension API than the one Cursor currently ships. Check Cursor's About dialog for its current API level and, if needed, install an older release of the extension from the Marketplace's version history.

Is there a way to keep settings permanently synced instead of re-importing?
Symlinking both editors' settings.json to a single file in a dotfiles repo, as covered in Step 10, keeps them in sync automatically. Just be aware that a Cursor auto-update can occasionally recreate the settings folder and break the symlink, so it's worth re-checking after major version bumps.

Is it safe to sideload a .vsix file instead of installing through the registry?
Yes, as long as you download it directly from the extension's official VS Code Marketplace listing rather than a third-party mirror, and double-check the publisher ID for lookalikes before installing. Sideloading skips the registry's own listing checks, so treat the source URL with the same caution you'd apply to any executable download.

Can I use Cursor Rules to keep AI edits consistent with my linter and formatter extensions?
Yes. A rules file in .cursor/rules can instruct the Agent to defer to your existing ESLint, Prettier, or language-server configuration instead of proposing its own style, which is the main way to keep AI-driven edits and extension-enforced formatting from working against each other.

Related Coverage

• VS Code to Cursor Migration: 12 Steps, 60 Min [2026]
• React vs Vue Charts Setup: 12 Steps, 90 Min [2026]
• React vs Vue Dark Mode Setup: 12 Steps, 90 Min [2026]
• React vs Vue Accessibility Setup: 12 Steps, 90 Min [2026]
• React vs Vue GraphQL Setup: 13 Steps, 100 Min [2026]