You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Delete shows "Plugin deleted." toast but the plugin stays live #413
Deleting a plugin from the cursor.directory dashboard shows a success toast ("Plugin deleted.") but the plugin remains live afterward.
Plugin:firmaradar-mcp (a remote MCP server)
Steps to reproduce
Open the plugin's ⋯ menu → Delete.
A toast confirms "Plugin deleted."
Reload the directory → the plugin is still listed.
What I've already checked
It still appears in an incognito / logged-out window, so it's server-side — not my local cache.
It persisted overnight, so it's not just propagation lag.
The listing shows "1 install" (not mine — I don't use Cursor myself).
The ⋯ menu also shows a greyed-out "Verification requested" state and an "Unpublish" option, in case either is relevant.
Expected
Delete actually removes the listing.
Ask
Could you remove the firmaradar-mcp listing? I've re-submitted an updated version and want to avoid a duplicate. Happy to share any internal IDs / the dashboard URL if that helps. Thanks for maintaining the directory! 🙏
Update: I also tried Unpublish from the same ⋯ menu — it behaves identically to Delete (success toast, but the listing stays live, including in an incognito/logged-out window). So this isn't Delete-specific; both mutations are effectively no-ops for this listing.
My best guess at the root cause: the listing appears stuck in the "Verification requested" state (shown greyed-out with a spinner in the ⋯ menu). It looks like the auto-review (the composer-2 SDK agent) never resolved, and while the listing is pinned in that pending-verification state, no state changes (delete/unpublish) take effect.
Since I can't move it from my side, could you force-remove firmaradar-mcp on the backend? Happy to share any IDs. Thanks!
Important additional context — this is blocking, not cosmetic:
The listing is now Unpublished (hidden), but Delete still does nothing (the no-op described above), so I can't fully remove it.
Because the stuck listing still occupies the repo/name slot, I can't submit a replacement — a new submission for the same GitHub repo (Tiwas/firmaradar-mcp) / same name is rejected as a duplicate.
Net effect: the plugin is currently not listed at all — the old entry is hidden + undeletable, and a fresh submission is blocked. I have no way to fix this from my side.
Could you delete the stuck firmaradar-mcp entry on the backend so I can re-submit cleanly? Happy to provide any IDs / the dashboard URL. Thanks!
Deleted plugin still shows under profile that can't be re-published, and new submission can't reuse the same repo or slug. This is blocking us from publishing plugins to cursor.directly
Hey @Tiwas, thanks for the report, and sorry it sat here this long. This is a known problem on cursor.directory: for some listings the owner Delete / Unpublish action returns success but the row never changes, so the plugin stays live and keeps its slug and repository URL. There's no self-serve path that works for those listings right now; they need to be cleared by the team on the backend.
I've attached your report to the internal ticket that tracks this, with firmaradar-mcp as the listing. @FeiyouG, if yours is a different slug, post it here and it goes in the same batch. I'll update when it's cleared.
Update: #443 changes the delete action so a delete that removes no row fails with an error instead of showing "Plugin deleted." It won't clear the listing from this report by itself, that still needs the backend cleanup tracked internally, but it stops the UI from claiming success when nothing happened, which is the part this repo can fix.
Activity
Tiwas commentedon Jun 23, 2026
Update: I also tried Unpublish from the same ⋯ menu — it behaves identically to Delete (success toast, but the listing stays live, including in an incognito/logged-out window). So this isn't Delete-specific; both mutations are effectively no-ops for this listing.
My best guess at the root cause: the listing appears stuck in the "Verification requested" state (shown greyed-out with a spinner in the ⋯ menu). It looks like the auto-review (the
composer-2SDK agent) never resolved, and while the listing is pinned in that pending-verification state, no state changes (delete/unpublish) take effect.Since I can't move it from my side, could you force-remove
firmaradar-mcpon the backend? Happy to share any IDs. Thanks!Tiwas commentedon Jun 23, 2026
Important additional context — this is blocking, not cosmetic:
Tiwas/firmaradar-mcp) / same name is rejected as a duplicate.Could you delete the stuck
firmaradar-mcpentry on the backend so I can re-submit cleanly? Happy to provide any IDs / the dashboard URL. Thanks!FeiyouG commentedon Sep 1, 2026
+1
Deleted plugin still shows under profile that can't be re-published, and new submission can't reuse the same repo or slug. This is blocking us from publishing plugins to cursor.directly
deanrie commentedon Oct 5, 2026
Hey @Tiwas, thanks for the report, and sorry it sat here this long. This is a known problem on cursor.directory: for some listings the owner Delete / Unpublish action returns success but the row never changes, so the plugin stays live and keeps its slug and repository URL. There's no self-serve path that works for those listings right now; they need to be cleared by the team on the backend.
I've attached your report to the internal ticket that tracks this, with
firmaradar-mcpas the listing. @FeiyouG, if yours is a different slug, post it here and it goes in the same batch. I'll update when it's cleared.deanrie commentedon Oct 8, 2026
Update: #443 changes the delete action so a delete that removes no row fails with an error instead of showing "Plugin deleted." It won't clear the listing from this report by itself, that still needs the backend cleanup tracked internally, but it stops the UI from claiming success when nothing happened, which is the part this repo can fix.