Cursor allows users to install, or defaults users into installing, an outdated version of ccashwell.solidity-workbench, even though Open VSX reports 0.6.2 as the latest version.
Open VSX metadata confirms the current version:
https://open-vsx.org/api/ccashwell/solidity-workbench/latest returns version 0.6.2
Open VSX search for solidity-workbench also returns ccashwell.solidity-workbench at version 0.6.2
This makes Cursor users miss recent language-server fixes and gives the impression that the extension is broken or stale when the upstream Open VSX package is current.
Steps to Reproduce
Open Cursor IDE.
Open the Extensions view.
Search for Solidity Workbench or ccashwell.solidity-workbench.
Install the extension from Cursor’s marketplace UI.
Check the installed extension version.
Expected Behavior
Cursor should install the latest compatible Open VSX version, currently 0.6.2.
If Cursor intentionally selects an older version because of engine compatibility, the UI should explain that clearly and show why the latest version was skipped.
Cursor uses the Open VSX registry rather than the VS Code Marketplace, and our mirror can sometimes serve an older version of an extension.
The most common reason is engine compatibility. Cursor bundles VS Code 1.105.1, and if your extension’s engines.vscode field in package.json requires a newer version, Cursor will install the last compatible version instead of the latest. Since you’re the publisher of solidity-workbench, it’s worth checking whether v0.6.2’s engines.vscode constraint exceeds ^1.105.0. If it does, relaxing that constraint (if your extension doesn’t truly need newer VS Code APIs) would make the latest version available in Cursor.
If the engine constraint isn’t the issue, it may be a sync delay in Cursor’s Open VSX mirror. In that case, you can install the latest version manually:
Nope it’s just the cache, my extension targets ^1.85.0. Of course one could manually install the VSIX but this should absolutely not be necessary, doing so leaves users on stale versions that require manual updates using the same hacky approach. A better solution would be to improve the caching layer.
Chris is right in that this is completely unnecessary and leaves users on older versions of extensions with no obvious indicators. On top of that, I’m not sure your explanation actually jives with reality. Reality appears the caching layer is simply broken.
What is the explanation for Python – Open VSX Registry (ms-python.python) which was last published two months ago (version 2026.4.0), requires VS Code ^1.95.0, but Cursor installs version 2025.6.1 which isn’t even in the versions drop-down? How does that make sense? Is the caching layer 2 months behind? Is Cursor using some other upstream, because that version isn’t on open-vsx.org? Is there monitoring in place on this caching layer to ensure it works for paying customers? Are there plans to update the bundled VS Code version so updated extensions continue to work?
Chris, thanks for confirming. Since your extension targets ^1.85.0, engine compatibility is ruled out and the root cause is the mirror’s cache delay.
@Scott_W - your Python extension example is a good one. I checked the Open VSX registry: the latest ms-python.python (2026.4.0) requires ^1.95.0, which IS compatible with Cursor’s VS Code 1.105.1. So engine compatibility isn’t the blocker here either. The version 2025.6.1 you’re seeing doesn’t appear in Open VSX’s version list at all, which suggests it was installed from a different source before Cursor’s marketplace transition.
One question to help narrow this down: was the Python extension already installed before a recent Cursor update, or did you install it fresh? If it was already present, the old version may have carried over from the pre-transition marketplace and isn’t being picked up by the Open VSX update path.
Both of you raise a fair point about manual VSIX installation not being a real solution. I’m passing this along to our engineering team.
@mohitjain On my old laptop, it’s certainly possible the Python extension was “installed” from somewhere else, if Cursor imported it from VS Code (I honestly can’t remember). But this new laptop has only ever had Cursor installed and I’ve only ever installed extensions through the IDE, until this Python issue came up.
While trying to figure out what was going on with my Python extension, I completely uninstalled it and deleted all the ms-python* related files/directories in my profile directory. I then installed the 2026.4.0 version of the ms-python extension from Open VSX (accessed by clicking “Marketplace” under Resources on the extension page in Cursor) by using the drag-and-drop method.
Once I’ve done that, Cursor sees the new version installed but still reports all of the old data from the marketplace. Something is definitely bugged here.
That screenshot helps a lot. So to confirm: even on a fresh machine with no VS Code history, after a clean manual install of the latest version from Open VSX, Cursor still shows stale marketplace metadata (showing “Last Released: 2025-06-17” when the actual latest is from 2026) and disables auto-updates.
That rules out the carry-over theory. There are two issues here:
Cursor’s mirror isn’t serving the latest version of ms-python.python, which is why you had to install manually in the first place
Once installed via VSIX, Cursor marks it as externally sourced and won’t auto-update from the registry going forward
I’m escalating both of these to our engineering team. The combination means even users who proactively install the correct version get stuck without future updates.
I don’t have a workaround that avoids the manual VSIX path for now. I’ll follow up here when I have an update from the team.
