Detailed Analysis
A developer building a Claude Desktop plugin has encountered a functional gap in Anthropic's plugin system: the `userConfig` field, designed to prompt users for custom values (like a username) during plugin installation, silently fails to trigger any input prompt. The plugin's manifest correctly declares a required `username` field intended for injection into the MCP server's environment variables via the `${user_config.username}` templating syntax, and the plugin installs and "enables" without error. However, the promised configuration dialog never appears, leaving the environment variable substitution either empty or falling back to a hardcoded default in the developer's own MCP server code. Notably, the developer observes that Claude Desktop's plugin installation flow lacks the "Configure options" affordance that exists for standalone MCP extensions, meaning there is no manual workaround to supply the missing value after the fact.
This bug sits at an important seam in Anthropic's rapidly expanding plugin ecosystem. Claude's plugin architecture—which bundles skills, MCP servers, hooks, and other extensions into a single distributable package—is still new, and features like `userConfig` are meant to make plugins from third-party marketplaces (e.g., GitHub-hosted repos) safely configurable without requiring users to hand-edit JSON or shell environment variables. If `userConfig` prompts don't fire, plugin authors are forced into awkward workarounds: silently defaulting sensitive fields, requiring post-install manual configuration through undocumented channels, or abandoning per-user customization entirely. For fields marked `sensitive: true` (e.g., API keys), this isn't just an inconvenience—it's a security and usability blocker, since there'd be no clean path to collect credentials without hardcoding them into a repo-committed config file.
The discrepancy between MCP extensions (which do apparently support a "Configure options" post-install flow) and full plugins (which do not) suggests that the plugin packaging format was extended from the MCP extension model without fully porting over the configuration UI. This kind of inconsistency is typical in fast-moving developer platforms where manifest schemas (`plugin.json`, `mcp.json`) get expanded to support richer bundling before the corresponding client-side UI in Claude Desktop catches up. It also reflects the tension between shipping developer-facing extensibility features quickly—useful for driving adoption of the plugin/marketplace model—and ensuring each declared manifest field actually has an enforced runtime behavior across every installation surface (CLI, Desktop app, VS Code extension, etc.).
More broadly, this incident is a small but telling data point in the maturation of Claude's agentic tooling ecosystem. As Anthropic pushes plugins, MCP servers, skills, and subagents as composable building blocks for third-party developers, the reliability of manifest-driven configuration becomes as important as the underlying model capabilities. Bugs like this—silent failures rather than explicit errors—are particularly costly for developer trust, since they can mask misconfiguration until a plugin behaves unexpectedly in production. For a platform aiming to be the substrate for a broader "agent app store," ensuring that declarative configuration (userConfig, permissions, tool scoping) is enforced consistently across every install path will be a prerequisite for third-party developers to build plugins that handle credentials and user-specific settings safely at scale.
Read original article →