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:
- Disabled plugins’ ce-* commands still show in / autocomplete (especially after /resume)
- /plugins doesn’t label enabled vs off = everything looks installed
- 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 ).