[BUG] Uninstalled claude.ai plugins are re-enabled server-side within seconds and synced into every Claude Code session
Preflight Checklist
- [x] I have searched existing issues and this hasn't been reported yet
- [x] This is a single bug report (please file separate reports for different bugs)
- [x] I am using the latest version of Claude Code
What's Wrong?
On my claude.ai account, four plugins from the knowledge-work-plugins marketplace can't be removed. Uninstalling shows a success notification, but the server re-enables them within seconds. This happens on claude.ai (web) and in Claude Desktop, even with every other Claude client closed.
Since a few weeks, Claude Code (CLI, Linux) has synced these plugins into ~/.claude/plugins/synced/<org>_<account>/ and loaded them into every session. Their skills appear in the skill list, and disabling them in Claude Code does not persist across launches.
Affected plugins and their server IDs, from the synced manifest.json:
Plugin Server-Plugin-ID installationPreference
desktop-commander | plugin_01S1HcuzG4CPx8bTxZDQAguG | available
engineering | plugin_01FTLa86dhbVJ3HB1LdHdhN7 | available
productivity | plugin_014WxCYbLf7f3uw2isHFR9US | available
ai-firstify | plugin_01N1WJAviip299WSJ5mduv97 | available
All four are available, not installed by default. Their return can't be explained by the default-install behavior from #74706.
The behavior has gotten worse over time. At first the plugins came back after a page reload. Now they come back within seconds. It has been going on for months.
What Should Happen?
An uninstall on claude.ai should clear the account-side enabled flag permanently. Plugins removed there should no longer be synced into Claude Code.
Workaround
Setting "syncClaudeAiPlugins": false in ~/.claude/settings.json stops the sync into Claude Code. I verified this with a fresh session. It does nothing for the account itself, though, and it also blocks every plugin I might want from claude.ai.
Related
- #74706: plugins revert within ~60s after uninstall. Closed as stale, not fixed.
- #85218: Desktop uninstall never clears the account-side enabled flag. Closed as stale, not fixed.
- Older reports, closed without a fix: #39686, #37340, #49260, #40475.
- A support request with account details is open: conversation ID 215476206780593.
Error Messages/Logs
Steps to Reproduce
- Quit Claude Desktop on all devices and close all Claude Code and Cowork sessions.
- On claude.ai, uninstall one of the plugins above. A success notification appears.
- Wait a few seconds. The plugin is listed as installed or enabled again.
- Start Claude Code. The plugin is re-downloaded into ~/.claude/plugins/synced/… and its skills are loaded.
Claude Model
None
Is this a regression?
I don't know
Last Working Version
_No response_
Claude Code Version
2.1.287
Platform
Anthropic API
Operating System
Windows
Terminal/Shell
PowerShell
Additional Information
_No response_
Showing cached comments. Read the full discussion on GitHub ↗
4 Comments
Network evidence: the disable is accepted, then immediately ignored on read
I captured what happens in the browser when I remove engineering on claude.ai:
{ "id": "plugin_01FTLa86dhbVJ3HB1LdHdhN7", "name": "engineering",
"enabled": false, "installation_preference": "available", ... }
"viewer": { "added": true,
"installed": { "enabled": true, "installation_preference": "available",
"can_toggle": true, "can_remove": true } }
No error is returned, and no other client is involved. The write succeeds, but the read ignores it.
All five affected plugins (engineering, productivity, desktop-commander, ai-firstify, cowork-plugin-management) show "provenance": { "source": "default" } in that listing, even though installation_preference is "available". This looks like the listing is built from the default set, and the user's disable override isn't applied to source: default entries.
Follow-up: the disable is stored, but the listing and the sync ignore it
Reading the single plugin right after disabling it:
GET /api/organizations/<org>/plugins/plugin_014WxCYbLf7f3uw2isHFR9US (productivity)
{ "id": "plugin_014WxCYbLf7f3uw2isHFR9US", "name": "productivity",
"enabled": false, "installation_preference": "available", ... }
At the same time:
So the per-plugin record has enabled: false, but the listing endpoint and the plugin sync resolve the state differently, apparently letting source: "default" override the user's disable. That is why the UI shows it re-enabled and every client re-downloads it.
Follow-up: uninstall returns 404, admin route is 403. No self-service path left on personal accounts
The same plugin (productivity, plugin_014WxCYbLf7f3uw2isHFR9US) is reported differently depending on the endpoint:
So the uninstall can't find an install record, the per-plugin record says disabled, and the account listing still says enabled. My guess is that the plugin comes from the default set, not from an install record, and that the account-level disable is never applied to it.
The admin route (PUT …/marketplaces/<mp>/plugins/productivity/installation-preference with not_available, and admin-list) returns 403 on a personal plan. Org settings are Team/Enterprise only. That leaves personal-plan users with no way at all to remove these plugins. Only Anthropic can fix this server-side, and the request_id above should point to the right code path.
Same here on a personal Max account (Windows 11, Claude Desktop + Claude Code), with different plugins from the same knowledge-work-plugins marketplace: brand-voice, data and customer-support (plus the hidden cowork-plugin-management, which isn't listed on claude.ai at all).
Remove on claude.ai/customize/plugins shows "Brand Voice has been removed", but the row and the count never change. I first tried a few weeks ago with the same result; they are still installed today. All four are still synced into ~/.claude/plugins/synced/ with installationPreference "available", and the desktop app log shows "fetchAutoInstalledPlugins: 0 plugins", so nothing on the client side is re-adding them.