The Agentic IDE Extension Blind Spot

On this page

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](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.

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.

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.

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

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

What changed #

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

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 down 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 setMarketplace 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 showspublishedBy , 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 documentation, Extensions: [https://cursor.com/help/customization/extensions](https://cursor.com/help/customization/extensions)
- Open VSX Registry: [https://open-vsx.org/](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

• cursor

• vscode

- open-vsx
- supply-chain
- ai-coding-agents

Author

Vignesh Naikoti

safedep.io

Share

The Latest from SafeDep blogs #

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

Deep-Live-Cam Supply Chain Attack: Technical Analysis #

A malicious dependency in Deep-Live-Cam loads a clipboard hijacker. We trace the installation trigger, Telegraph delivery, and Windows and macOS persistence.

A malicious npm package hidden three dependencies deep: the ulid-xyz delivery chain #

ulid-xyz is a remote access trojan we reported to OSV as MAL-2026-6672. It reached developers as a third-level transitive dependency of ioredis-xyz, a copy of the real Redis client planted in 28...

Introducing SafeDep Threat Intel #

SafeDep Threat Intel gives SOC and cyber defense teams the malicious package intelligence behind SafeDep's platform, to query or to push into the tools they already run.

Mini Shai-Hulud Strikes Again: openapi-react-query-codegen #

An attacker exploited a flawed GitHub Actions workflow to publish 10 malicious versions of @7nohe/openapi-react-query-codegen (671K downloads/month) via npm OIDC trusted publishing. The payload uses...

Ship Code. #

Not Malware. #

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