Docs: plugin install vs disable vs uninstall lifecycle and enabled-state ground truth

Summary

There is no single doc that explains install vs disable vs uninstall for Cursor marketplace plugins, or where enabled state actually lives on disk. This causes repeated misdiagnosis (especially CLI-first users) when disabled plugins still appear under /plugins or when slash commands from a disabled plugin persist in autocomplete.

Related: #130 (opt-out / deactivate skills globally).

Problem

Users (and agents troubleshooting plugin state) commonly assume:

• If ~/.cursor/plugins/cache/cursor-public/<slug>/ exists → plugin is enabled
• If /plugins lists a plugin → plugin is enabled
• Moving/deleting cache dirs → valid way to disable

None of these match observed behavior on Cursor CLI (agent 2026.06.19, Linux).

Observed semantics

Action	Disk effect	Agent effect
Install (marketplace)	Creates/updates cache under ~/.cursor/plugins/cache/cursor-public/<slug>/	Plugin ID added to enabled list
Disable (toggle in /plugins detail or Settings)	Cache retained	Plugin ID removed from enabled list
Uninstall (/plugin uninstall <name>)	Removed from installed scope	Must reinstall from marketplace

Ground truth for enabled plugins

SQLite: ~/.config/Cursor/User/globalStorage/state.vscdb

cursor.plugins.installedIds.no-team
cursor.plugins.installedIds.no-workspace   # workspace-scoped overrides

Value is a JSON array of numeric marketplace plugin IDs.

Naming confusion: key says installedIds but value represents enabled IDs only — not "all plugins ever installed."

CLI ~/.cursor/cli-config.json does not store plugin enable state.

UX gaps (product — filing on forum too)

1. CLI /plugins mixes marketplace browse + installed list; disabled (cached-off) plugins appear without an ENABLED / DISABLED badge.
2. Slash menu can retain stale entries in agentData.cacheStorage.agentEnvironment.slashMenuItems.* (same vscdb); staff track this class of bug on forum #161008.
3. /resume sessions may keep prior plugin context; new session required after toggling plugins.

Requested doc changes (this repo or cursor.com/docs)

1. Lifecycle table (install / disable / uninstall) with filesystem + vscdb effects.
2. Explicit note: plugins/cache/ = downloaded artifacts; not enable state.
3. CLI section: /plugins is browse + manage; verify enable state via Settings or vscdb keys above.
4. Troubleshooting: after disable, start new agent session; slash menu cache may need fresh session (not /resume).
5. Link to forum threads for product UX bugs (uninstall button redirect, slash menu cache).

Environment

• OS: Linux (Ubuntu)
• CLI: agent 2026.06.19-20-24-33
• Example: compound-engineering (ID 680) CACHED-OFF but cache present; cursor-team-kit (677) ENABLED — only distinguishable via vscdb, not /plugins UI.

Note

cursor/cursor has issues disabled; forum is the right channel for IDE/CLI product bugs. This issue is scoped to documentation / plugin-spec clarity so plugin authors and power users stop fighting the cache directory.

Start by locating the plugin documentation and reviewing the /plugins and /plugin uninstall entry points alongside ~/.config/Cursor/User/globalStorage/state.vscdb and ~/.cursor/cli-config.json. Document the install, disable, and uninstall lifecycle, identify the enabled-state keys, and include the requested CLI and fresh-session troubleshooting guidance.