/add-plugin GitHub imports can get stuck on stale plugin versions

Where does the bug appear (feature/product)?

Cursor IDE

Describe the Bug

Plugins installed from a GitHub repo via /add-plugin <github-url> can get pinned to a stale commit and then cannot be upgraded or permanently removed from Cursor.

We reproduced this with https://github.com/monk-io/monk-plugin as an example plugin, but the behavior appears to be related to the /add-plugin repo-import flow rather than this specific plugin.

In our case, /add-plugin https://github.com/monk-io/monk-plugin created a local/non-team marketplace. Cursor then installed the plugin from an old pinned commit even though the upstream repo had newer tagged releases and the marketplace UI showed a recent “last updated” time.

Removing the marketplace from the Customize tab does not persist. After reloading the Cursor window or restarting the app, the marketplace comes back. Deleting ~/.cursor/plugins contents also does not permanently remove it; Cursor rehydrates the marketplace/cache and reinstalls the same stale commit.

There does not appear to be a way to upgrade a plugin installed through this /add-plugin <github-url> method, nor a way to permanently remove the generated marketplace.

Steps to Reproduce

  1. Use Cursor on macOS.
  2. Run:
    /add-plugin https://github.com/monk-io/monk-plugin
    
  3. Observe that Cursor creates a local/non-team marketplace for the repo.
  4. Install the plugin from that marketplace.
  5. Compare the installed plugin commit/version under ~/.cursor/plugins/cache/... with the latest upstream GitHub commit/tag.
  6. Observe that the installed plugin is pinned to an older commit.
  7. Remove the generated marketplace from the Customize tab.
  8. Reload the Cursor window or restart Cursor.
  9. Observe that the marketplace comes back.
  10. Delete relevant local plugin cache folders, for example:
    rm -rf ~/.cursor/plugins/cache/*
    rm -rf ~/.cursor/plugins/marketplaces/*
    
  11. Restart Cursor.
  12. Observe that Cursor recreates the marketplace/cache and still installs the stale pinned version.
  13. Re-run /add-plugin https://github.com/monk-io/monk-plugin.
  14. Observe that it still resolves to the old pinned commit rather than the latest repo state.

Expected Behavior

A plugin installed via /add-plugin <github-url> should have a clear lifecycle:

  • Cursor should either install the latest commit from the tracked branch, or clearly show that it is pinned to a specific commit.
  • If the upstream repo changes, there should be a visible way to refresh/update the installed plugin.
  • Reinstalling the plugin should not keep using a stale pinned commit when newer repo content is available.
  • Removing a user-added marketplace from the Customize tab should persist across reloads/restarts.
  • Deleting local cache should not cause Cursor to silently rehydrate a stale marketplace that the user already removed.
  • The UI’s “last updated” information should match the version/commit actually installed, or separately show both marketplace index version and installed plugin version.

Operating System

MacOS

Version Information

Version: 3.8.22
VS Code Extension API: 1.105.1
Commit: 46fb7aafe279d7c72346febe68c2e004b7d1de60
Date: 2026-06-22T21:41:16.291Z
Layout: glass
Build Type: Stable
Release Track: Default
Electron: 40.10.3
Chromium: 144.0.7559.236
Node.js: 24.15.0
V8: 14.4.258.32-electron.0
xterm.js: 6.1.0-beta.256
OS: Darwin arm64 25.5.0

Additional Information

This may be related to existing team/custom marketplace cache-refresh issues, but this report is specifically about the personal /add-plugin <github-url> flow where there is no apparent Dashboard Auto Refresh or manual Refresh control.

We found that:

  • ~/.cursor/plugins/cache/... can remain pinned to an old commit.
  • ~/.cursor/plugins/marketplaces/... may contain a newer indexed copy.
  • Cursor still loads/reinstalls from the stale cache.
  • Removing the marketplace from Customize does not permanently remove the server-side/local registration.
  • Deleting local plugin cache folders does not solve it because Cursor recreates them on reload/restart.
  • There is no obvious UI to see installed commit vs latest commit.
  • There is no obvious UI to force upgrade or clear the pinned commit for /add-plugin installs.

Workaround:

  • Installing the plugin as a local development plugin via ~/.cursor/plugins/local/<plugin-name> or symlinking a local checkout works, but bypasses the /add-plugin marketplace flow entirely.

Does this stop you from using Cursor

No - Cursor works, but with this issue

Hi @nooga Thanks for the detailed report and repro steps. I was able to reproduce the stale pin behavior on our side.

The issue appears to be specific to the personal /add-plugin <github-url> flow: after the repo advances, re-running /add-plugin can continue resolving the previously pinned plugin version instead of refreshing to the latest repo state. I’ve passed this along to the engineering team with the reproduction details.

For now, the most reliable workaround is the one you found: install the plugin as a local development plugin by cloning it locally and using ~/.cursor/plugins/local/<plugin-name>, or symlinking a local checkout there.

we’ll let you know any updates to the status of bug report as we have them. Thank you again for the excellent report with lots of details!

Thanks for confirming, and I appreciate the quick response @kevinn!