[BUG] Account-synced plugins cannot be removed: they reappear after removal from the desktop app AND claude.ai, and are invisible to the CLI

Same bug on macOS, with some extra evidence that may help narrow it down. Probably also related to #92850 and #83891.

Environment: macOS 27.0, Claude desktop app 2.110.1 (Code tab, bundled Claude Code 2.1.271; CLI 2.1.273). Account belongs to an organization with no org-wide plugin settings that we know of.

Same install timestamp as this report. In local-agent-mode-sessions/<account>/<org>/rpm/manifest.json, 12 of the 13 knowledge-work-plugins entries carry updatedAt between 2026-09-16T00:04:15Z and 00:04:21Z (sales alone is 2026-09-16T14:40:04Z). That matches the 2026-09-16T00:04:15Z install time above on a different OS, which suggests one server-side install or re-sync event rather than anything local.

What happens when toggling off in Customize. I switched off Sales, Marketing, Legal, Finance, Operations and Brand Voice, closed Customize, waited, and started a new Code-tab session (2026-09-17 17:14 UTC). That session's skill listing contained:

• Sales (36 skills), Marketing (8), Finance (8): still loaded, despite being switched off
• Legal, Operations, Brand Voice: absent, so the toggle worked for these three at that moment

Marketing and Finance kept switching themselves back on in Customize across several attempts. Legal later did the same.

Desktop logs while Customize was open (~/Library/Logs/Claude/):

• claude.ai-web.log: 33 × [REACT_QUERY_CLIENT] QueryClient error: {"name":"Error","message":"Plugin not found."} between 17:05 and 17:16 UTC, roughly every 10 seconds. There were none on earlier days, so they appear only while the plugin settings are being changed. The log does not say which plugin.
• main.log: repeated [PluginsFetcher] fetchPluginEnabledState: 13 overrides. The [CCD] … N plugin(s) go to Claude Code count for new sessions dropped from 13 to 10 right after the toggles, so some changes do reach the session and some are reverted.

The local manifest is not a workaround. Desktop rewrites rpm/manifest.json with every pack at installationPreference: "available" at app launch and roughly hourly while running. I kept the six packs at "unavailable" in that file continuously (re-applied within seconds of every rewrite), and a new session still loaded all 75 of their skills. So the file is not what decides which plugins load. As in #92850, claude plugin list does not show these plugins, so the CLI offers no way out either.

Expected: a pack switched off in Customize stays off and does not load into new sessions.
Actual: some packs stay off, and others (here Sales, Marketing, Finance, later Legal) revert and keep loading, while the web client logs Plugin not found. on each attempt.

Another Windows case, but a different shape from the original report, and with a workaround that works here. Both points may help narrow down what distinguishes the affected installs.

The CLI does see them here. The original report has claude plugin list printing "No plugins installed", with the plugins living in the desktop app's local-agent-mode-sessions/.../rpm/manifest.json. On this machine they are ordinary synced plugins under ~/.claude/plugins/synced/<uuid>_<uuid>/, and the CLI lists them:

$ claude plugin list
Synced from claude.ai:
  pdf-viewer@synced                 Version: 0.2.0   Status: loaded
  cowork-plugin-management@synced   Version: 0.2.2   Status: loaded

Same marketplace as in the report. synced/<uuid>_<uuid>/manifest.json:

{
  "name": "pdf-viewer",
  "version": "0037",
  "updatedAt": "2026-09-16T00:04:19.340978Z",
  "marketplaceName": "knowledge-work-plugins",
  "installationPreference": "available"
}

The updatedAt values here are 2026-09-16T00:04:15Z and 00:04:19Z, inside the same window both earlier reports give, on a third machine. That supports the "one server-side event" reading.

Removal is partial here too. Four plugins arrived: pdf-viewer, cowork-plugin-management, design, legal. I turned all four off for the claude.ai account. design and legal are now in ~/.claude/plugins/.trash/, moved there the next morning, and have stayed gone. pdf-viewer and cowork-plugin-management kept syncing back, and the manifest listing them was rewritten again this morning. That is the same split the macOS comment reports: some packs stay off, others revert.

For those two the switch also flips back visibly. I turned them off in the claude.ai web settings and later found them switched on again without having touched them. The macOS comment reports the same thing in the desktop app's Customize panel, so it is not specific to one surface.

Workaround that holds, for this shape of the bug. Because the CLI can see them, the per-plugin disable applies:

$ claude plugin disable pdf-viewer@synced
Successfully disabled plugin: pdf-viewer

It writes "pdf-viewer@synced": false into enabledPlugins in ~/.claude/settings.json, which is user scope and therefore survives the next sync:

$ claude plugin list --json
{"id": "pdf-viewer@synced", "version": "0.2.0", "scope": "synced", "enabled": false}
{"id": "cowork-plugin-management@synced", "version": "0.2.2", "scope": "synced", "enabled": false}

After /reload-plugins, the skills and the plugin's MCP server are gone from the session. syncClaudeAiPlugins: false is the broader version of the same idea and stops the download itself.

This does not help anyone in the original report's situation, since it depends on the CLI seeing the plugin, and there claude plugin list is empty. But it does mean the two situations are distinguishable from the CLI, which may be worth checking when reproducing: whether claude plugin list shows the plugin seems to track whether any removal path works at all.

One inconsistency worth a look on its own. claude plugin list --json reports "scope": "synced", but that value is not accepted by the scope flag:

$ claude plugin uninstall --help
  -s, --scope <scope>  Uninstall from scope: user, project, or local (default: "user")

So the scope a plugin reports is not a scope any uninstall can target. This matches the reference docs, which say install, update and uninstall do not apply to synced plugins. It still sends anyone who tries toward a flag that cannot express the answer.

Environment

• Windows 11 Home 10.0.26200, Git Bash and PowerShell
• Claude Code 2.1.276, terminal CLI signed in with a claude.ai account
• Personal Max account, owner of its own organization, no org plugin policy; the plugins are not marked required by your org

Same bug on a third setup: Linux CLI (Claude Code 2.1.287, Debian 13) plus claude.ai web and Claude Desktop. Personal paid account, owner of its own org, no org plugin policy. Full details in #98894.

• Affected: desktop-commander, engineering, productivity, ai-firstify (all knowledge-work-plugins, all installationPreference: "available"), plus cowork-plugin-management.
• Removal never sticks: for months, uninstalling on claude.ai (web) or Desktop shows success, but the plugins are back. At first that took a page reload, now it takes seconds. This happens even with every other Claude client closed, so no local reconcile is putting them back.
• Timing matches: the CLI's ~/.claude/plugins/synced/<org>_<account>/ bucket on my server was created on 2026-09-17, right after the 2026-09-16 00:04 UTC event reported above. Since then all four plugins have loaded into every CLI session.
• CLI workaround: "syncClaudeAiPlugins": false in ~/.claude/settings.json, but it blocks all claude.ai plugins and does nothing for web/Desktop.

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:

1. PUT https://claude.ai/api/organizations/ORG-ID/plugins/plugin_01FTLa86dhbVJ3HB1LdHdhN7/enabled → 200. The response body confirms the change:

{ "id": "plugin_01FTLa86dhbVJ3HB1LdHdhN7", "name": "engineering",
"enabled": false, "installation_preference": "available", ... }

1. The client then immediately calls mine?kind=plugin&limit=1000. The same plugin is listed as enabled again:

"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:

• mine?kind=plugin&limit=1000 lists the same plugin with viewer.installed.enabled: true and provenance.source: "default".
• The account sync still delivers it to Claude Code (~/.claude/plugins/synced/<org>_<account>/manifest.json lists productivity).

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:

• GET /api/organizations/<org>/plugins/<id>: enabled: false (the disable is stored)
• GET …/marketplaces/<mp>/plugins/account-list-plugins: enabled: true
• GET …/library/…/mine?kind=plugin: enabled: true, provenance.source: "default"
• DELETE /api/organizations/<org>/plugins/<id>: 404 {"type":"not_found_error","message":"Plugin not found."}, request_id req_011Cfd9akHMbvaHtMYwFxPCR

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.