[Bug] Cowork: ghost plugin from hidden marketplace can't be uninstalled, triggers OAuth popup on every launch
Summary
A Cowork plugin (nimble) installed from a marketplace that is no longer surfaced in any management UI persists as a "ghost" install — Cowork launches its bundled MCP server on every startup, which triggers a browser OAuth popup to mcp.nimbleway.com. The plugin cannot be removed through any user-accessible path:
- Not listed in Claude Desktop → Settings → Plugins
- Not listed in claude.ai web UI plugin/connector management
- Not listed in Cowork's own
cowork-plugin-managementplugin (its agent-facing tools are read-only —list_plugins,search_plugins,suggest_plugin_installonly) - Not searchable as an installable plugin from any of the above (so it's not just "uninstall hidden" — the entire marketplace appears delisted from the user's account view)
The claude-code CLI layer is exonerated — claude mcp list, ~/.claude/plugins/installed_plugins.json, ~/.claude/settings.json, and ~/.claude/plugins/known_marketplaces.json are all clean. The plugin lives entirely in Cowork's local-agent-mode-sessions/.../rpm/ cache.
Reproduction (limited)
I can't fully repro from a clean account because the marketplace is no longer accessible to me. The historical install path was likely:
- Some time ago, the
knowledge-work-pluginsmarketplace (IDmarketplace_01QRn9XAjzzeAokB5nPWVMxP) was visible in Cowork's plugin browser under a feature flag. - I clicked install on the
nimbleplugin (IDplugin_01BB1HUyHKrddLdPpkTMBUvE), among ~12 from that marketplace (data, finance, brand-voice, prisma, productivity, design, pdf-viewer, legal, enterprise-search, bio-research, cowork-plugin-management). - The marketplace was later hidden / feature-flagged off / deprecated for my account.
- The installs persist on disk and at the account level, but no UI surfaces them anymore.
Expected behavior
If a plugin is installed and active enough to spawn an MCP subprocess on every startup, there must be a UI path to uninstall it — even if the source marketplace is no longer surfaced.
Actual behavior
On every Cowork (and apparently Codex too) startup:
$ pgrep -lf mcp-remote
36043 npm exec mcp-remote@latest https://mcp.nimbleway.com/mcp --header Authorization:Bearer ${NIMBLE_API_KEY}
36129 node /Users/<user>/.npm/_npx/.../mcp-remote https://mcp.nimbleway.com/mcp --header Authorization:Bearer ${NIMBLE_API_KEY}
The literal ${NIMBLE_API_KEY} in argv (env var was never exported) fires a browser OAuth popup to nimble's auth flow. Process cwd is the Cowork session directory, confirming Cowork is the parent.
Diagnostic info
Launcher config (<org-dir>/rpm/plugin_01BB1HUyHKrddLdPpkTMBUvE/mcp.json):
{
"mcpServers": {
"nimble-mcp-server": {
"command": "npx",
"args": ["-y", "mcp-remote@latest", "https://mcp.nimbleway.com/mcp",
"--header", "Authorization:Bearer ${NIMBLE_API_KEY}"]
}
}
}
Manifest entry (<org-dir>/rpm/manifest.json, before quit-handler purge):
{
"id": "plugin_01BB1HUyHKrddLdPpkTMBUvE",
"name": "nimble",
"marketplaceId": "marketplace_01QRn9XAjzzeAokB5nPWVMxP",
"marketplaceName": "knowledge-work-plugins",
"installedBy": "user",
"installationPreference": "available"
}
Behavior of Cowork's quit handler: purges rpm/<plugin-id>/ directories on quit and rewrites manifest.json from 12 entries to either 2 or 0 (observed both [bio-research, pdf-viewer] and [] in successive writes). However, on next launch the cache appears to be re-populated from server-side state, restoring the OAuth-triggering plugin.
Workarounds attempted
- Searching all on-disk Claude/Codex configs (
~/.claude.json,~/Library/Application Support/Claude/claude_desktop_config.json,~/.codex/config.toml, all.mcp.jsons, marketplaces, installed_plugins.json, mcp-needs-auth-cache.json, etc.) → all clean. The plugin is only in the Coworkrpm/cache. - Killing the orphaned process → it respawns on next Cowork startup.
- Quitting Claude Desktop fully → the
rpm/cache is purged but the plugin is presumably re-fetched server-side on next launch.
Last-resort interim mitigation (not yet applied): 127.0.0.1 mcp.nimbleway.com in /etc/hosts to blackhole the OAuth endpoint without modifying any Anthropic state.
Asks
- A UI path to remove plugins from delisted/hidden marketplaces — most directly, surface installed plugins in the plugin manager regardless of whether their source marketplace is currently visible.
- As an immediate fix for affected users: an account-side cleanup tool or support process to remove ghost installs.
- Consider whether plugin installs from feature-flagged or experimental marketplaces should auto-uninstall when the marketplace is no longer surfaced to the account, to avoid this class of orphan.
Environment
- Cowork inside Claude Desktop (Claude.app v1.5354.0)
- macOS 26 (Tahoe), Darwin 25.4.0
- Also affects
codexCLI startup on the same machine (suggesting the OAuth flow is shared at the OS level, or the same plugin layer is read by both)
Related
- #42315 — plugin-bundled MCP servers should be opt-in (related class of issue)
- #40175 — Cowork stale-write race (different bug, tangentially relevant since file edits to
rpm/are not a safe workaround on this code path)
This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗