[BUG] [PLUGIN] CLI and desktop resolve different plugin identities

Status Open
Reported on v2.1.236
Maintainer reply None cached
Activity 0 comments · opened Sep 6, 2026

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?

I made a plugin for a model-to-model pattern (advisor/workhorse). When a plugin with userConfig options is installed via claude plugin install --config, the config values are stored in pluginConfigs and CLI resolves the identity as <plugin>@<plugin>. My plugin is called the-advisor, so it's like this - (e.g., the-advisor@the-advisor), but the desktop app resolves the same installed plugin as <plugin>@inline (e.g., the-advisor@inline).

Since the keys don't match, the desktop app's MCP server receives empty strings for every userConfig option. The plugin appears installed and runs, but all configuration is silently missing.

What Should Happen?

The same plugin installation should receive the same config values regardless of whether it's launched from the CLI or the desktop app, right? A config set with --config at install time should apply in both contexts.

Error Messages/Logs

No error is shown — the failure is silent. The MCP server starts, but every `userConfig` value arrives as `""`. The only way to diagnose it is inspecting the running server's environment:


ps eww <pid>  # look for CLAUDE_PLUGIN_DATA — it names the resolved identity


The server process launched by the CLI shows `CLAUDE_PLUGIN_DATA` containing `the-advisor@the-advisor`. The server launched by the desktop app shows `the-advisor@inline`. The `pluginConfigs` entry only exists under one of these keys.

Steps to Reproduce

  1. Create or install a plugin that declares userConfig options in plugin.json. In my case, i used my own plugin - claude plugin install the-advisor@the-advisor --config advisor_model=claude-opus-5
  2. Open a CLI session. The plugin's MCP server starts and receives advisor_model=claude-opus-5 as expected.
  3. Open a desktop app session. The same plugin's MCP server starts but receives advisor_model="".
  4. Verify by inspecting the running server process:

``bash
ps eww $(pgrep -f advisor_server)
`
The
CLAUDE_PLUGIN_DATA` path differs between CLI and desktop app launches, confirming different resolved identities.

Claude Model

Not sure / Multiple models

Is this a regression?

I don't know

Last Working Version

CLI (Homebrew): 2.1.236, and the Desktop app (internal): 2.1.260

Claude Code Version

2.1.236 (Claude Code)

Platform

Anthropic API

Operating System

macOS

Terminal/Shell

Terminal.app (macOS)

Additional Information

  • The plugin identity can be observed via the CLAUDE_PLUGIN_DATA environment variable on the running MCP server process.
  • There is no plugin-side workaround that survives a reinstall. Manually adding a duplicate pluginConfigs entry keyed to @inline works per-machine but is lost on claude plugin install or claude plugin update.
  • /plugin configure also does not work inside the desktop app (only in the terminal CLI), so desktop-only users have no way to set config at all.
  • This affects any marketplace plugin that relies on userConfig — not specific to this plugin.

I know guys are super busy with the bajillion different issues i see here. Full disclosure: Claude helped me write up this draft, which i tweaked. Thank you in advance for all your hard work, and I'm happy to buy someone a cup of coffee for their trouble 😀

You guys rule.

View original on GitHub ↗