Plugin updates, local overrides, and cursor.directory trust boundary. Documentation gaps

Discussions
, ,
1

After reading Plugins, Plugins Reference, and MarketPlace Security three behaviors aren’t documented.

1. Client-side update delivery for public marketplace plugins

The Marketplace Security page confirms every update is manually reviewed before publishing. What isn’t documented is what happens on the developer’s machine after that review:

  • Does Cursor automatically download and apply the new version to an already-installed plugin?

  • Is there a way to see installed vs. latest version, or to pin a specific version?

(I’m aware of the “Enable Auto Refresh” toggle for team marketplaces and the open bug around it — this question is about the public marketplace.)

2. Local modifications to installed third-party plugins

The docs describe testing your own plugin under ~/.cursor/plugins/local/. They don’t describe what happens if you edit files of an installed third-party plugin (e.g. under the cache directory):

  • Are local edits preserved, overwritten, or undefined on upstream update?

  • What’s the recommended pattern — fork the repo and load as a local plugin?

3. Trust boundary for cursor.directory vs. official Marketplace

The Marketplace Security page makes strong guarantees for official Marketplace plugins (reviewed, open-source, MCP respects allowlist/blocklist). The docs point to cursor.directory for “community plugins and MCP servers” but don’t describe its trust model:

  • Do items installed via cursor.directory go through any review pipeline at Cursor?

  • Can a community plugin author push an update that adds hooks, skills, MCP servers, or rules to my install without explicit consent?

  • Given that plugins are largely markdown/script files that the AI follows as instructions, is there an integrity check or diff review step before updates take effect?

Clear documentation of the trust boundary for community-sourced plugins would help teams make informed adoption decisions.

Thanks.

4

I have the same questions - appreciate for this post and the answers to come!

6

Hey @Msusu (and @qcb!)

When we publish a reviewed update to a marketplace plugin, your Cursor client will automatically pick up the new version on its next refresh cycle (triggered by window focus or periodic checks). The installed version is pinned to a specific git commit SHA internally, so updates are atomic. The old version is replaced, not patched. There’s currently no UI to compare installed vs. latest version or to pin a specific version yourself.

Installed marketplace plugins live in are treated as managed, disposable artifacts. Edits you make there will survive until the next upstream update, at which point the old directory is replaced. If you want to customize a third-party plugin, the supported path is to fork the repo.

cursor.directory is community-driven. Items there don’t go through the same review pipeline. Naturally, we’d remove anything that is harmful to users, but it’s not a vetted, curated collection the way the marketplace is.

Importantly, cursor.directory doesn’t work like the marketplace. You’re not “installing a plugin” that auto-updates. It’s a directory of individual elements (rules, skills MCP servers, etc.) that you can add to your Cursor setup via an “Add to Cursor” or “Copy” button. Each is a one-time action. There’s no background sync pulling in upstream changes, so an author can’t push updates into your environment without you explicitly adding them again.