The Agentic IDE Extension Blind Spot

Vignesh Naikoti
9 min read

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 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, and goes through its own server to get there. From Cursor’s extensions page:

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.

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.

What the import sends

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

cursor --help, Cursor 3.12.30
--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.

List them in Visual Studio Code
code --list-extensions --show-versions
And again in Cursor
cursor --list-extensions --show-versions

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

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
Output
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.

One extension
cursor --install-extension <publisher>.<name>

What changed

ExtensionVisual Studio CodeCursor after importOpen VSX latest
esbenp.prettier-vscode12.1.012.4.012.4.0
formulahendry.code-runner0.12.00.12.20.12.2
vscode-icons-team.vscode-icons12.17.012.19.012.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: [email protected]. 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.

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
Output
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.

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 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 are already being attacked. Extensions need the same care you give a lockfile.

References

  • cursor
  • vscode
  • open-vsx
  • supply-chain
  • ai-coding-agents

Author

SafeDep Logo

Vignesh Naikoti

safedep.io

Share

The Latest from SafeDep blogs

Follow for the latest updates and insights on open source security & engineering

Background
SafeDep Logo

Ship Code.

Not Malware.

Start free with open source tools on your machine. Scale to a unified platform for your organization.