[BUG] Plugins show as "(installed)" in marketplace but don't appear in Installed tab

Found 3 possible duplicate issues:

1. https://github.com/anthropics/claude-code/issues/14202
2. https://github.com/anthropics/claude-code/issues/13509
3. https://github.com/anthropics/claude-code/issues/14689

This issue will be automatically closed as a duplicate in 3 days.

• If your issue is a duplicate, please close it and 👍 the existing issue instead
• To prevent auto-closure, add a comment or 👎 this comment

🤖 Generated with Claude Code

Found 3 possible duplicate issues: 1. Bug: Project-scoped plugins incorrectly detected as installed globally #14202 2. [[BUG] #13509](https://github.com/anthropics/claude-code/issues/13509) 3. [[Bug] Plugin not visible to Claude despite being visible with /plugins command with --plugin-dir flag #14689](https://github.com/anthropics/claude-code/issues/14689) This issue will be automatically closed as a duplicate in 3 days. If your issue is a duplicate, please close it and 👍 the existing issue instead To prevent auto-closure, add a comment or 👎 this comment 🤖 Generated with Claude Code

[[BUG] #13509](https://github.com/anthropics/claude-code/issues/13509) is close, but that seems to be limited to local marketplaces, and may be subtly different in other ways. This happened with a marketplace installed from a Github repo.

I'm running into the same issue as well, have you figured out any work arounds?

As side solution I have a project that will allow you to enable installed plugins in other local directories and also track plugins from one place: https://github.com/kaldown/ccpm

Running to the same issue with superpowers@superpowers-marketplace and dev-browser@sawyerhood/dev-browser (they suddenly disappeared from the plugin installed view - although cc says they are installed). In some cases plugin appear in the marketplace view but installation is not working.

Experiencing similar issues with custom marketplace plugins. Can confirm the state file disconnect - installed_plugins.json shows the plugin but the system doesn't load it.

Workaround we're trying: Use a prompt-based SessionStart hook that tells Claude where to find plugins directly.

We're building claude-1337 - a plugin marketplace that attempts to sidestep this issue using a SessionStart hook:

{
  "hooks": {
    "SessionStart": [
      {
        "hooks": [
          {
            "type": "prompt",
            "prompt": "To find available plugins:\n1. Read `~/.claude/plugins/known_marketplaces.json` → get `installLocation`\n2. Read `{installLocation}/.claude-plugin/marketplace.json`\n3. Plugin content at `{installLocation}/plugins/<name>/`"
          }
        ]
      }
    ]
  }
}

The idea is to bypass the loader entirely - Claude reads the marketplace files directly at session start instead of relying on the plugin system to recognize what's installed. Will share updates on how well this works.

Root cause hypothesis: The plugin loader and state file have different definitions of "installed". State file records intent, loader checks something else (timestamps? git SHAs? version comparisons?) that gets out of sync.

Update: type: prompt hooks don't fire. Switched to type: command with a shell script that echoes the prompt content — that works.

{
  "hooks": {
    "SessionStart": [
      {
        "hooks": [
          {
            "type": "command",
            "command": "${CLAUDE_PLUGIN_ROOT}/hooks/session-start.sh"
          }
        ]
      }
    ]
  }
}

Where session-start.sh just echoes the instructions:

#!/bin/bash
cat << 'PROMPT'
To find available plugins:
1. Read ~/.claude/plugins/known_marketplaces.json
2. Read {installLocation}/.claude-plugin/marketplace.json
3. Plugin content at {installLocation}/plugins/<name>/
PROMPT

So there may be two separate bugs here:

1. Plugin loader not recognizing installed plugins (this issue)
2. type: prompt hooks not firing (possibly related?)

Oh nice to know there is a hook for session start!

Update: Workaround confirmed working.

SessionStart hook with type: command (not type: prompt) successfully injects context at session start.

Example: https://github.com/yzavyas/claude-1337/blob/main/plugins/core-1337/hooks/session-start.sh

Update: Workaround confirmed working. SessionStart hook with type: command (not type: prompt) successfully injects context at session start. Example: https://github.com/yzavyas/claude-1337/blob/main/plugins/core-1337/hooks/session-start.sh

That's not very secure to install plugins by shell script. Context if it could change after some time, leaving to vulnerability exposure. Please consider creating plugin following the Claude code conduct

Adding another data point on Arch Linux.

Environment:

• OS: Arch Linux
• Claude Code: latest

Exact symptom:
Same plugin installed and working in one Claude Code session, but in a second concurrent session:

❯ /plugin marketplace add obra/superpowers-marketplace 
  ⎿  Error: Marketplace 'superpowers-marketplace' is already installed.

❯ /plugin install superpowers@superpowers-marketplace 
  ⎿  Plugin 'superpowers@superpowers-marketplace' is already installed.

❯ /plugin → Installed tab
  ⎿  No plugins or MCP servers installed.

❯ /superpowers:[TAB]
  ⎿  (no autocompletion, commands not recognized)

The plugin is marked as installed in state files but the plugin loader doesn't recognize it for loading in the second session. Cannot apply the workaround (rm state files) because the first session has the plugin "in use."

This appears related to #14202 - the underlying issue seems to be that plugin installation state is global but plugin loading is per-session, without proper synchronization between them.

This is fixed , validated with 1 enterprise ghec private marketplace and with 1 public gh marketplace. fyi.

I just ran into this issue, exactly as described at the top of this issue thread (showing installed but with 0 installations, and no assets are usable), so it is not resolved (at least not in all cases). MacOS, v2.1.19.

Also seeing this bug.

Bug Report:

• Issue: /plugin install reports plugin as "already installed" when it's not actually installed for the current project
• Steps to reproduce:

a. Install a scoped plugin for one project
b. Switch to a different project directory
c. Try to install the same plugin
d. CLI incorrectly reports: "Plugin xxx is already installed"

• Expected behavior: Plugin should be installed for the new project
• Actual behavior: Plugin is not installed and cannot be used, but CLI prevents installation
• Workaround attempted: Removed installed_plugins.json, plugin cache, and marketplace directory - issue persists

The CLI appears to be checking marketplace presence rather than actual installation state for the current project

@htxryan I am not using apple (using Linux) however if you find workaround https://github.com/shibuido/claude-plugin-install (or https://gist.github.com/gwpl/cd6dcd899ca0acce1b4a1bc486d56a9e ) working for you please give a heads up that works also on MacOS, or if you find way to patch it to also work on MacOS , PRs are welcome or github issues with enough detail for my AI/LLM to make a patch for MacOS without having one. Otherwise, I hope issue will be fixed upstream soon so we don't have to use workarounds.

I have the same issue.

Plugins Discover Installed Marketplaces (←/→ or tab to cycle)

Install Plugins

❯ ✔ frontend-design [development] (installed) · 247.7K installs
Create distinctive, production-grade frontend interfaces ...

◯ context7 [development] [Community Managed] · 140K installs
Upstash Context7 MCP server for up-to-date documentation ...

✔ superpowers [development] (installed) · 118.9K installs
Superpowers teaches Claude brainstorming, subagent driven...

◯ code-review [productivity] · 117.7K installs
Automated code review for pull requests using multiple sp...

✔ github [productivity] (installed) · 102.4K installs
Official GitHub MCP server for repository management. Cre...
↓ more below

----
and yet :

Plugins Discover Installed Marketplaces (←/→ or tab to cycle)

Manage plugins

No plugins or MCP servers installed.
---
Version: 2.1.66
Session name: /rename to add a name
Session ID: 94f2ddf7-d92f-4502-a9f0-15d4b9da2377
cwd: C:\01_Projects\01a_Coding\02_CodingProjects\grapplingprimitivesastro
Login method: Claude Max Account
Email: gfabrot@gmail.com

Model: Default Opus 4.6 · Most capable for complex work
Memory:
Setting sources: Project local settings

Hey folks! Sorry about this. We have a fix ready in our next release that will show the correct state in the "Installed" tab of the plugins UI.

We're also looking into the root cause of why installations can sometimes silently fail in the first place.

> Update: Workaround confirmed working. > > SessionStart hook with type: command (not type: prompt) successfully injects context at session start. > > Example: https://github.com/yzavyas/claude-1337/blob/main/plugins/core-1337/hooks/session-start.sh That's not very secure to install plugins by shell script. Context if it could change after some time, leaving to vulnerability exposure. Please consider creating plugin following the Claude code conduct

The script is a prompt. That's the same mechanism plugins use. The security question is content trust, not delivery, and plugins don't solve that either.

Claude's own injection detection is improving as a layer of defense. Tested this with a summarize call and was pleasantly surprised. https://justin.poehnelt.com/posts/rewrite-your-cli-for-ai-agents/