Claude Code shipped two releases back to back on September 23 and 24, 2026 — v2.1.281 and v2.1.282 — and between them, five separate fixes went into claude plugin uninstall: a scope deadlock that made some plugins unremovable, two data-loss bugs that quietly deleted a plugin’s saved options and secrets, and a messaging change so the CLI stops lying about what it kept. That’s an unusual concentration of fixes on one command in 48 hours, and it means the uninstall path was worse than most users realized.
It also isn’t the whole story. Nine open GitHub issues, several confirmed reproduced by Anthropic engineers, describe plugin removal failing in ways neither release touches — mostly one layer up, in the Desktop app and the claude.ai account-sync plugin system that the CLI fixes don’t reach.
The Two-Release Sprint
Both release note bodies are on the public releases page. Here’s the plugin-uninstall-relevant subset, in order.
v2.1.281, released September 23:
Fixed
claude plugin uninstallrefusing to remove a project-scope plugin that isn’t enabled, saying it is “enabled at project scope” whileclaude plugin disablesays it is already disabled
Fixed
claude plugin updatefailing for project-scoped plugins when--scopeis omitted — it now resolves the scope the plugin is installed at instead of assuming user
Changed
claude plugin uninstall --jsonand the/plugindialog to say a plugin’s data was kept when its folder stays because another installed plugin uses it or install records cannot be read
v2.1.282, released September 24 — the very next day:
Fixed plugin uninstall reporting success and deleting the plugin’s saved options when its settings file still enabled it or could not be read; it now stops and names the file
Fixed plugin uninstall deleting a plugin’s saved options and secrets when the list of installed plugins could not be read after the removal; they are now kept and the uninstall says so
Read together, the pattern is: uninstall previously assumed its own writes always succeeded, and treated “I couldn’t read the file I needed” the same as “there’s nothing here to keep.” Two releases in a row rewired that assumption for different files in the uninstall path — first the scope/enable state, then the plugin’s own saved options and secrets.
The Bug the First Fix Actually Closes
The first line in v2.1.281 is a near-exact match for issue #73697, opened July 3, 2026:
claude plugin uninstall <name>@<market>refuses withPlugin "<name>@<market>" is enabled at project scope (.claude/settings.json, shared with your team). To disable just for you: claude plugin disable <name>@<market> --scope local. The suggested commandclaude plugin disable <name>@<market> --scope localrefuses withalready disabled at local scope;--scope projectlikewise reportsalready disabled at project scope.
That’s a genuine deadlock — every command the CLI itself suggests as a next step refuses with a contradictory error. The report notes it was “the same symptom as #62966,” an earlier report closed as stale by the stale-bot in June with an invitation to reopen if still relevant, and still fully reproducible five months later on a different OS. As of this writing, #73697 remains open on GitHub even though the wording of v2.1.281’s fix describes exactly the bug it reports — the changelog and the issue tracker haven’t been reconciled yet, which is worth knowing if you’re searching issues to check whether your specific error is already fixed.
If you hit this exact contradiction — uninstall says “enabled,” disable says “already disabled,” at any scope — v2.1.281 or later should resolve it. If your plugin won’t uninstall for a different reason, keep reading.
What’s Still Broken: Local State
Two categories of plugin-removal bugs are still open, and neither is touched by the two releases above.
#84867 — filed August 7, reproduced by an Anthropic engineer on 2.1.233 — reports that any plugin operation that rewrites ~/.claude/settings.json (adding a marketplace is enough; install, uninstall, and remove all trigger it) can silently drop an unrelated top-level setting. The original report caught "effortLevel": "max" vanishing after a plugin removal, with the running session falling back silently to high. The engineer’s reply narrowed the mechanism: the rewrite doesn’t drop arbitrary unrecognized keys — a custom key survives, and a valid effortLevel value survives — it drops a recognized key whose value isn’t in the currently valid set (low, medium, high, xhigh; "max" isn’t one of them), with no prompt and no warning. That’s a different failure mode from either of the two v2.1.282 fixes above, which are scoped to a plugin’s own saved options and secrets, not arbitrary settings the plugin write happens to pass over. As of writing this is still open and unfixed — the maintainer’s own comment says “keeping this open as reproduced,” and recommends backing up settings.json before any plugin operation until it lands.
#92667 — filed September 7 — points out there’s no command at all to remove a project- or local-scope install record once its projectPath no longer exists on disk. claude plugin uninstall --help has no path selector; claude plugin prune only removes auto-installed dependencies, not path-keyed records; nothing in the .claude directory’s documented cleanupPeriodDays retention sweep touches plugins/. The only workaround is hand-editing installed_plugins.json, which the report itself flags as unsupported.
What’s Still Broken: Desktop and claude.ai Sync
This is the larger group, and it’s a different subsystem entirely — none of it goes through the claude plugin uninstall CLI path that the two releases patched.
| Issue | What happens |
|---|---|
| #83891 | Uninstalling from claude.ai → Customize → Plugins shows a success toast and an empty list, but a reload restores the plugin — reproduced on 2 of 9 plugins tested, still installed 24+ hours later, still loading its skills and MCP servers into new sessions |
| #95157 | Six account-synced “knowledge-work” plugins can’t be removed from the Desktop app, claude.ai’s own documented toggle, or the CLI — claude plugin list reports zero plugins installed while ~50 skills keep loading anyway |
| #92850 | The same family of 17 account-scoped plugins has no remove, disable, or uninstall control anywhere in the Skills panel UI, and is invisible to claude plugin list because it’s injected via repeated --plugin-dir flags, not the marketplace/settings path |
| #90607 | Bundled inline plugins (zoom-plugin, pdf-viewer, prisma) re-enable themselves after being disabled; zoom-plugin fails every session with a 401 against a token the account never created |
| #93553 | A self-uploaded plugin’s install record freezes at its first version — every later upload, update, or uninstall attempt silently fails to persist past a restart |
| #93466 | Desktop’s Directory → Plugins panel renders duplicate cards under the wrong marketplace and exposes no uninstall control at all, even though claude plugin list on the same machine returns the correct set |
| #89984 | Uninstalling from the Desktop UI is a one-way door: the browser only lists already-installed plugins, so a plugin removed from the app disappears from the catalog too and can’t be reinstalled from the UI |
The common thread across all seven: the Desktop app and claude.ai’s account-plugin sync each maintain their own idea of what’s installed, and none of them fully agree with ~/.claude/settings.json or installed_plugins.json — the two files the September fixes actually touch. A CLI-side fix to claude plugin uninstall has no code path into a sync bug in the Desktop app’s plugin browser or claude.ai’s account toggle.
A Practical Checklist Before You Trust “Uninstalled”
Given the above, treat a plugin removal as unverified until you’ve checked more than the confirmation message:
- Run
claude plugin listafter any uninstall, not just the CLI’s own success message — several of the open issues above show a plugin gone from one surface (Desktop UI, claude.ai) while still loading skills or MCP servers in the CLI, or vice versa. - Back up
~/.claude/settings.jsonbefore any plugin install, uninstall, or marketplace change, per #84867’s workaround, until the recognized-key-with-invalid-value drop is fixed.cp ~/.claude/settings.json ~/.claude/settings.json.bakcosts nothing. - If a plugin came from an account-synced marketplace (
knowledge-work-pluginsor similar) rather than one you added yourself, know that neither the Desktop app’s remove control nor claude.ai’s documented “turn the plugin off” toggle is reliable for that category as of this writing — #92850 and #95157 both report the CLI can’t even see these plugins to offer a fallback. - If
claude plugin uninstallandclaude plugin disablecontradict each other (“enabled at project scope” vs. “already disabled”), update to v2.1.281 or later before filing a new report — that specific deadlock is fixed. - Check
~/.claude/plugins/installed_plugins.jsondirectly if a project- or local-scope plugin won’t uninstall after a project directory has moved or been deleted; there’s currently no command that reaches a stale path-keyed record (#92667).
FAQ
Does updating to v2.1.282 fix all plugin uninstall bugs? No. It fixes two specific data-loss bugs in the CLI’s local settings rewrite (a plugin’s saved options and secrets being dropped), and v2.1.281 the day before fixed a project-scope enable/disable deadlock. Neither release touches the Desktop app’s plugin browser or claude.ai’s account-sync plugin toggle, where a separate set of at least seven open issues describe uninstalls that don’t persist.
Why does claude plugin list show no plugins installed when skills are still loading? This happens with account-synced plugins injected via repeated --plugin-dir flags rather than the standard marketplace/enabledPlugins path — see #92850 and #95157. claude plugin list only reports marketplace-installed plugins, so it can’t see or remove this category at all.
What’s the safest way to remove a plugin from a shared project right now? Use claude plugin uninstall <name>@<marketplace> from the CLI on v2.1.281 or later, then confirm with claude plugin list and by checking .claude/settings.json’s enabledPlugins key directly, rather than trusting the success message alone — especially for anything installed through the Desktop app or an account sync rather than the CLI.
Is there a way to force-remove a stale project-scope install record? Not through a documented command as of v2.1.282. claude plugin uninstall has no path selector, and claude plugin prune only targets auto-installed dependencies. The only current workaround is hand-editing ~/.claude/plugins/installed_plugins.json, which isn’t officially supported.
Related Reading
- Claude Code Plugin Marketplace: Complete Guide to Installing, Building, and Publishing Plugins (2026)
- Claude Code Shipped CLAUDE_CODE_MAX_MCP_DESCRIPTION_LENGTH on Sept 22. It Fixes One of the Four Things Three Bug Reports Asked For (2026)
- .mcp.json Configuration Reference: Complete Guide for Claude Code MCP Setup
Browse real-world plugin and .mcp.json configurations in our gallery.