Disabled plugin slash commands still appear in Cursor CLI / menu; /plugins shows no ENABLED/DISABLED state

Support Bug Reports
,
1

Where does the bug appear (feature/product)?

Cursor CLI

Describe the Bug

After disabling a marketplace plugin (e.g. compound-engineering), / autocomplete can still show ce-* slash commands from prior sessions. CLI /plugins lists cached plugins alongside enabled ones with no ENABLED/DISABLED label — looks like disable failed when ~/.cursor/plugins/cache/cursor-public/<slug>/ still exists.

Steps to Reproduce

  1. Install compound-engineering via /plugins
  2. Toggle OFF in /plugins detail (do not uninstall)
  3. Start new CLI session (not /resume)
  4. Type / — observe whether ce-* commands still appear
  5. Compare: sqlite3 ... state.vscdb "SELECT value FROM ItemTable WHERE key LIKE 'cursor.plugins.installedIds%';"

Expected Behavior

Disabled plugins absent from slash autocomplete; /plugins shows clear enable state

Operating System

Linux

Version Information

Cursor CLI (agent): 2026.06.19-20-24-33-653a7fb

OS: Ubuntu 24.04.4 LTS (Noble)
Kernel: Linux 6.17.0-35-generic x86_64

For AI issues: which model did you use?

Composer 2.5 Fast

Additional Information

Related:
GitHub cursor/plugins#136 (docs)
GitHub cursor/plugins#130 (opt-out)

Does this stop you from using Cursor

No - Cursor works, but with this issue

5

Hey there @TomCruiseMissile

Can you share how you’re toggling off the plugin in the CLI?

My understanding is that it’s only possible to uninstall a plugin, not disable. If you can share a screenshot or your exact command, that would be great!

7

Thanks for asking & the quick reply! I need to correct my repro steps.

You’re right, there is no CLI command or /plugins detail toggle for disable.

My bad on writing “Toggle OFF in /plugins detail.”

That control does not exist in the CLI UI on my build (agent 2026.06.19, Ubuntu 24.04).
Your understanding matches mine: in CLI, /plugin exposes install/uninstall, not disable.

What actually happened: disable was done by the Cursor CLI coding agent during troubleshooting, not by me through a supported UI, and not via a documented CLI command.

The agent edited the enabled-plugin list directly in SQLite:

1 │~/.config/Cursor/User/globalStorage/state.vscdb
2 │ cursor.plugins.installedIds.no-team|no-workspace

Example: compound-engineering (marketplace ID 680) was removed from that JSON array while its cache stayed at ~/.cursor/plugins/cache/cursor-public/compound-engineering/.

Verify:

1 │sqlite3 ~/.config/Cursor/User/globalStorage/state.vscdb \
2 │ “SELECT key, value FROM ItemTable WHERE key LIKE ‘cursor.plugins.installedIds%’;”

Despite the key name installedIds, the value is the currently enabled plugin ID list, not “everything ever downloaded.”

So to be clear: I did not find a supported “disable but keep installed” flow in CLI. The agent worked around that by editing state.vscdb. That workaround is part of what I’m reporting = CLI-first users may only see install/uninstall in /plugins, while enable state lives elsewhere with no obvious CLI control.

Symptoms that still motivated the report (accurate regardless of how disable was applied):

• After 680 was removed from installedIds, /plugins still listed compound-engineering
• / autocomplete still showed ce-* commands, especially after /resume (session kept old plugin context)
• Stale slash menu cache in the same vscdb (agentData.cacheStorage.agentEnvironment.slashMenuItems.*) also contributed

Corrected repro:

  1. Install compound-engineering via CLI /plugins
  2. Remove ID 680 from cursor.plugins.installedIds.* (today: agent-driven vscdb edit — no official CLI UI for this)
  3. Start a new agent session (not /resume)
  4. Type / — check whether ce-* still appears
  5. Compare with the state.vscdb query above

Sorry for the misleading original step. I conflated IDE-oriented staff guidance with a CLI toggle that isn’t there. Happy to re-test any official disable path you can point me to!

8

Thanks. That sounds like an agent doing work it shouldn’t have (manually manipulating, or “hacking” state.vscdb). Do you know what model you were using?

9

Understood. Editing state.vscdb directly isn’t a supported flow. I said that in my correction.

But framing this as “an agent doing work it shouldn’t” misses the product issue.

I asked the agent to disable plugins while keeping them cached = cut always-on context, turn them back on later. That’s exactly what your staff tell people to do (“toggle off, don’t uninstall” on #155640 ( Uninstall Plugin Button doesn't work )).

CLI has no disable UI. /plugins is install/uninstall. You confirmed that. So what should a CLI-first user do? Uninstall everything and re-download later? Burn context on plugins they don’t want active? Or let the agent find where enable state actually lives?

The agent found cursor.plugins.installedIds.* in SQLite because that’s where Cursor stores enabled plugins. Key name says “installed,” value is the enabled list. No official CLI control writes to it. The agent edited it because the feature you describe doesn’t exist on the surface I use.

That’s a parity gap, not agent misbehaviour.

The report isn’t about vscdb editing. It’s:

  1. Disabled plugins’ ce-* commands still show in / autocomplete (especially after /resume)
  2. /plugins doesn’t label enabled vs off = everything looks installed
  3. CLI-only users have no official disable-while-cached path

Those bugs exist whether disable happens via IDE toggle, uninstall, or an agent workaround.

Re: model = Composer 2.5 Fast (as listed in my original post) with cursor-agent, ~2026-06-22. Irrelevant nevertheless, because any model with shell, asked to disable plugins when CLI exposes no disable control, will land on the same config files.

That’s the point.

Happy to re-run with IDE Settings toggle or /plugin uninstall if you want a “clean” repro, but if stale slash commands persist after either, the bug stands.

Docs gap tracked here: cursor/plugins#136 ( Docs: plugin install vs disable vs uninstall lifecycle and enabled-state ground truth · Issue #136 · cursor/plugins · GitHub ).