---
title: "The Agentic IDE Extension Blind Spot"
description: "Cursor can install most of the same extensions you had in Visual Studio Code, but not the same versions. Its Import VS Code Configuration step sends only the extension name, never the version. It installs the newest version its own store has, which for most extensions is whatever Open VSX calls latest."
url: "https://safedep.io/blog/cursor-extension-import-versions"
author: "Vignesh Naikoti"
published: "2026-09-11"
---

# The Agentic IDE Extension Blind Spot

Did you move from Visual Studio Code to one of the new editors like Cursor, Windsurf or Google
Antigravity? Ever wondered what happens to all your Visual Studio Code extensions? They seem to work
fine in your new agentic IDE.

Microsoft's terms do not let Visual Studio Code forks use its marketplace. So they use
[Open VSX](https://open-vsx.org/) instead, a registry run by the Eclipse Foundation. But nobody
guarantees that the two carry the same extensions, or the same versions. That is where things get
messy.

Two stores and the same extension names, with no verification that the publisher is the same. That
is a supply chain attack waiting to happen.

## Summary

Cursor's **Import VS Code Configuration** step sends only the extension name, never the version you
were running. So Cursor installs the newest version Open VSX has. We held three extensions at old
versions and ran the import. All three came back at the version Open VSX calls newest. To keep the
version you want, name it yourself with `cursor --install-extension <publisher>.<name>@<version>`.
Make sure you have auto update off.

## The problem

Cursor can install all the same extensions you had in Visual Studio Code, but not the same
versions. An extension can arrive newer than the one you were using, older, or not at all.

The first time you open Cursor it offers to copy your Visual Studio Code setup across. Cursor calls
this **Import VS Code Configuration**, and you can run it again later from Cursor's settings. It
brings over your extensions, settings, keybindings and workspace history, and it replaces what
Cursor already had.

The import reads your Visual Studio Code extension list and copies only the name of each one. The
format is `publisher.extension_name`, for example `ms-python.python`. It does not have a version
attached to it.

So Cursor has nothing to match against. It searches its own extension store for that name and
installs the newest version it has there. For most extensions that store just forwards your request
to Open VSX, so you end up on whatever Open VSX calls latest.

A store you never chose decided which version you get. That extension can read your files and run
programs on your machine.

## The two extension stores

Cursor is built on Visual Studio Code, but it cannot use Microsoft's extension store. Microsoft's
rules do not let copies of the editor use it. So Cursor uses a different store,
[Open VSX](https://open-vsx.org/), and goes through its own server to get there. From Cursor's
[extensions page](https://cursor.com/help/customization/extensions):

> Cursor routes extension search and downloads through its own marketplace proxy
> (`marketplace.cursorapi.com`).

Both stores name extensions the same way. A name does not tell you who owns it, or which store it
came from. So the same name can mean different code in each store. Cursor says this in plain words
on the same page:

> The same `publisher.extension` name can point to different publishers or code on Open VSX than on
> the Microsoft Marketplace. Treat extension IDs like dependencies: install from publishers you
> trust.

Ask all three places for the same three names and you get three different answers.

![One extension name, ms-vscode.cpptools, asked of three separate stores: the Microsoft Marketplace, the Open VSX Registry and Cursor's own proxy. The same name goes to each one, and each one answers for itself](https://safedep.io/_next/static/immutable/media/ms-vscode-cpptools-marketplaces.0pg3v_php52c-.webp)

Cursor's store does not keep most extensions itself. It fetches them from Open VSX, runs its own
checks on them, and then serves you the copy Open VSX had. The checks can block an extension, but
they do not change which version you get. That part is still Open VSX's call.

The download links Cursor gives out show which extensions work this way. Ones that come from Open
VSX have `/open-vsx-mirror/` in the link. The few that Cursor keeps itself have
`/downloads/production/` instead.

Open VSX uploads many of its extensions through a bot account of its own instead of the author's
account. In 2025, Koi Security found a way to steal that account's publishing token. Whoever held it could
have pushed a new version of any extension in the store. It was
[reported in May 2025 and fixed in June 2025](https://www.securityweek.com/vulnerability-exposed-all-open-vsx-repositories-to-takeover/).

## What the import sends

Cursor's own help text shows what the install command takes.

```text title="cursor --help, Cursor 3.12.30" showLineNumbers=false
--install-extension <ext-id | path>
  Installs or updates an extension. The argument is either an extension id or a path to a VSIX. The identifier of an extension is '${publisher}.${name}'. Use '--force' argument to update to latest version. To install a specific version provide '@${version}'. For example:
```

You can ask for a version. You add `@` and the number. The import never does that. It sends the name
and takes whatever comes back.

## How to check it yourself

Install a few extensions in Visual Studio Code and hold them at old versions on purpose. Then open
Cursor and run **Import VS Code Configuration**. List them again in Cursor afterwards. Turn off
Cursor's extension auto update first, so auto update is not the reason anything changed.

```bash title="List them in Visual Studio Code"
code --list-extensions --show-versions
```

```text title="Before" showLineNumbers=false
esbenp.prettier-vscode@12.1.0
formulahendry.code-runner@0.12.0
vscode-icons-team.vscode-icons@12.17.0
```

```bash title="And again in Cursor"
cursor --list-extensions --show-versions
```

```text title="After" showLineNumbers=false
anysphere.remote-ssh@1.1.14
esbenp.prettier-vscode@12.4.0
formulahendry.code-runner@0.12.2
vscode-icons-team.vscode-icons@12.19.0
```

All three moved. Now ask Open VSX what it calls latest for those same three names.

```bash title="Ask Open VSX what it calls latest"
for id in esbenp/prettier-vscode formulahendry/code-runner vscode-icons-team/vscode-icons; do
  curl -s "https://open-vsx.org/api/$id/latest" | jq -r '[.namespace + "." + .name, .version] | @tsv'
done
```

```text title="Output" showLineNumbers=false
esbenp.prettier-vscode          12.4.0
formulahendry.code-runner       0.12.2
vscode-icons-team.vscode-icons  12.19.0
```

Those are the exact versions Cursor installed. You can also do one extension at a time, without the
full import.

```bash title="One extension"
cursor --install-extension <publisher>.<name>
```

## What changed

| Extension                        | Visual Studio Code | Cursor after import | Open VSX latest |
| -------------------------------- | ------------------ | ------------------- | --------------- |
| `esbenp.prettier-vscode`         | 12.1.0             | 12.4.0              | 12.4.0          |
| `formulahendry.code-runner`      | 0.12.0             | 0.12.2              | 0.12.2          |
| `vscode-icons-team.vscode-icons` | 12.17.0            | 12.19.0             | 12.19.0         |

All three landed on exactly the version Open VSX calls latest, and the version you were running
never came into it.

One extra line showed up in Cursor that was never in Visual Studio Code:
`anysphere.remote-ssh@1.1.14`. Anysphere is the company that builds Cursor, and it adds some of its
own extensions during setup.

Some extensions never make it into Cursor. Microsoft keeps a few of its own, such as the C/C++
extension and Pylance, available only in its own store. Open VSX does not have them, so there is
nothing for Cursor to fetch.

```bash title="Ask Open VSX for three Microsoft extensions"
for id in ms-vscode/cpptools ms-vscode/cpptools-extension-pack ms-python/vscode-pylance; do
  curl -s "https://open-vsx.org/api/$id/latest" | jq -r .error
done
```

```text title="Output" showLineNumbers=false
Extension not found: ms-vscode.cpptools latest
Extension not found: ms-vscode.cpptools-extension-pack latest
Extension not found: ms-python.vscode-pylance latest
```

Pylance is the odd one. Microsoft's store gives you `ms-python.vscode-pylance` from the publisher
`ms-python`, checked as `microsoft.com`. Ask Cursor's server for that same name and you get the
publisher `anysphere` at version 1.0.12. Anysphere is the company that builds Cursor. This is on
purpose, and Cursor's help page says so:

> Cursor publishes first-party **Anysphere** replacements for some widely used extensions that are
> unavailable on Open VSX.

It is still the clearest example of how all this works. One name, and a different company's code
behind it. Here the swap is on purpose, and it is safe. But the search that finds it cannot tell
that apart from some random person grabbing the same name.

## How this can go wrong

There are three ways this goes bad.

**A name nobody has taken.** Cursor recommends extensions when you open a project. Some of those
extensions were never published to Open VSX, so the name remained unclaimed and anyone could
register it. Koi Security researcher Oren Yomtov reported it in late November 2025. Cursor fixed it
on 1 December 2025, and Google Antigravity followed in late December. Koi grabbed six of the free
names themselves, with empty extensions, to keep attackers away from them. The Hacker News wrote
about it in
[VS Code Forks Recommend Missing Extensions](https://thehackernews.com/2026/01/vs-code-forks-recommend-missing.html).

**Someone else owning the same name.** This is the Pylance case, minus the part where the company
doing it is one you already trust. A name does not tie back to whoever owns it in Microsoft's store.

**A good publisher pushing a bad version.** This one is the hardest to catch, because the name, the
owner and the store all look right. The [DarkGPT extensions](https://safedep.io/blog/dark-gpt-vscode-malicious-extension)
did this on Microsoft's store. They used a signed Windows program and a hijacked DLL to run a
downloader in a hidden PowerShell window.

An extension can read your files, start programs, and get at your source code, your cloud keys and
your SSH keys. One machine is enough to put the rest of the team at risk.

## Auto update makes it worse

Extension auto update is on by default in Visual Studio Code, under `extensions.autoUpdate`, and
Cursor keeps that default. Auto update is good, because it gets security fixes to you fast. So
turning it off costs you something real. But it also means new code runs before anyone has looked at
it. It is the same problem as not pinning a version in a GitHub Actions workflow. If someone steals
a publisher's account, auto update ships their code to everybody.

## What to do

Cursor does check extensions, and it is worth knowing what those checks cover. It runs automated
malware and supply chain analysis on its own server before an extension shows up in search or gets
served as a download. Extensions that fail are blocked, and Cursor updates that blocklist from
extension threat intelligence. Publishers marked as verified have had their identity confirmed.
Malicious extensions have got past checks like these before, so treat them as filters and not as a
wall.

- Ask for the version you want. `cursor --install-extension <publisher>.<name>@<version>` installs
  that exact one. Make sure you have auto update off. Write those down where the team can see them,
  the same way you share a lockfile.
- After any import, run `cursor --list-extensions --show-versions` and compare it with the same list
  from the editor you left. Check every swap and every missing row. Do not assume the import copied
  what you had.
- Make new versions wait before they can be installed. Cursor has a setting for it,
  `extensions.installCooldownHours`, and team owners can set **Marketplace Install Cooldown
  (hours)** for everyone.
- Check the publisher in the store your editor actually reads, not on the Microsoft page you
  remember. For Open VSX, `https://open-vsx.org/api/<namespace>/<name>/latest` shows `publishedBy`,
  which is who uploaded it.
- Turn auto update off if someone will really check the updates. The downside is that known bad
  versions stay on your machine longer. If nobody has time to check, a waiting period is the better
  default.
- On a team plan, limit installs to a list you approve. Cursor takes an allowlist of publishers or
  extension names from the team dashboard, or through device management as `AllowedExtensions`.

An extension name works like a package name. Your editor looks it up when it installs, in a store
you did not pick. The [files AI coding agents read](https://safedep.io/blog/miasma-worm-ai-coding-agent-config-injection)
are already being attacked. Extensions need the same care you give a lockfile.

## References

- Cursor documentation, Extensions: https://cursor.com/help/customization/extensions
- Open VSX Registry: https://open-vsx.org/
- Open VSX registry takeover, SecurityWeek: https://www.securityweek.com/vulnerability-exposed-all-open-vsx-repositories-to-takeover/
- VS Code forks recommend missing extensions, The Hacker News: https://thehackernews.com/2026/01/vs-code-forks-recommend-missing.html
- VS Code forks expose users to recommended extension attacks, BleepingComputer: https://www.bleepingcomputer.com/news/security/vscode-ide-forks-expose-users-to-recommended-extension-attacks/
- Visual Studio Marketplace Terms of Use: https://cdn.vsassets.io/v/M190_20210811.1/_content/Microsoft-Visual-Studio-Marketplace-Terms-of-Use.pdf
- Mazin Ahmed on publishing malicious Visual Studio Code extensions: https://mazinahmed.net/blog/publishing-malicious-vscode-extensions