If a Plugin's details menu only shows "Configure options" and not "Configure," what does that mean?
It means this plugin doesn't bundle an MCP Server — it only declares its own userConfig settings. In this case, completing "Configure options" is all you need; there's no second configuration step to worry about missing, because it simply doesn't exist.
Conversely, if you only see "Configure" without "Configure options," it means the plugin itself doesn't expose any custom settings, but does include a bundled MCP server that needs connection configuration — in that case, "Configure" is the only entry point you need to deal with.
What's the practical difference between the claude Plugin configure shell command and going into the /plugin panel and clicking "Configure"?
Both ultimately trigger the same underlying configuration logic — the difference is in the interface and use case. The /plugin panel is interactive, requiring you to manually navigate menus inside a running Claude Code session; claude plugin configure is a command you can run directly from a shell without first entering an interactive session, which is more practical for deployment scripts, CI pipelines, or any automated scenario where manually operating an interface isn't convenient.
For an individual developer doing ordinary interactive work with Claude Code, either approach gets the job done — which one you pick mainly depends on whether you're already inside an interactive session at that moment.
If a Plugin update adds a new field to userConfig, are existing setting values preserved, or do you need to fill everything in again?
Public documentation doesn't give explicit guidance for this scenario, but it's reasonable to infer that existing field values are generally preserved (since they're stored in your settings file, and updating the plugin's code doesn't touch your settings file itself) — only the newly added field needs to be filled in separately. The more conservative approach is to proactively open "Configure options" once after a plugin update to check whether any new fields appeared and whether existing values still fit your needs, rather than assuming everything carries over unchanged.
If you're managing a project-scoped plugin configuration shared across a team, this post-update check matters even more, since a new field with no default value could silently break dependent functionality in a collaborator's environment.
How do I find out whether a Plugin includes a bundled MCP Server before installing, rather than discovering it only after?
The second step of the install flow (reviewing what the plugin will add) shows this — the details pane's "Will install" section lists the commands, agents, skills, hooks, and MCP and LSP servers the plugin adds. If an MCP server entry appears in that list, the plugin includes a bundled MCP server, and you'll likely need the "Configure" entry point afterward.
If you're installing from a local or custom marketplace where the panel shows "Components will be discovered at installation" instead of a concrete list, there's no way to know this ahead of time — you'll only find out by checking the install summary message or the details on the "Installed" tab after installation completes.
After installing a Claude Code Plugin that needs some user input — an API key, a custom path, a feature toggle — you might see two similarly named options appear: "Configure options" and "Configure." A recent release adds the shell command claude plugin configure <plugin> so you can trigger this without opening the interactive panel, but what's more worth understanding is that these two "Configure" buttons map to entirely different underlying mechanisms. Clicking the wrong one won't throw an error — it just won't do what you were trying to do.
When a plugin's manifest declares a userConfig field, the "Configure options" item appears in that plugin's details pane in the /plugin panel. This maps to a set of settings the plugin's author defined themselves — it could be a boolean toggle (enable some sub-feature or not), a string input (a custom Output Format preference), or any other parameter the plugin's own logic reads. Which fields get exposed is entirely up to the plugin author, and the interface you see is defined by the plugin itself, with no relation to any external service.
The other option, "Configure," only appears when a plugin includes a bundled MCP server (an MCP server packaged directly into the plugin), and it maps to that bundled server's own user_config settings — typically the authentication details that server needs to connect to an external service, such as an API key, account ID, or service endpoint URL. If the install summary shows "Plugin is now active, but its bundled MCP server needs configuration before it can start," that's telling you this MCP server hasn't been set up yet. Without completing "Configure," that server simply can't start, and whatever functionality in the plugin depends on it won't work.
This is the part most likely to cause confusion: if a plugin both declares userConfig and includes a bundled MCP server, its details menu shows both "Configure options" and "Configure" at the same time — differing by only the word "options" on the surface, but mapping to two completely separate sets of settings that affect, respectively, the plugin's own behavioral logic and whether its bundled MCP server can actually reach an external service. Mistake them for the same thing and configure only one, and you can end up with a plugin that looks fully installed while some feature depending on external data simply does nothing — a state that's genuinely easy to burn time troubleshooting.
Previously, completing either type of configuration required opening the interactive /plugin panel. The new claude plugin configure <plugin> shell command lets you trigger that configuration flow directly from a script or non-interactive environment, without first spinning up a full interactive session and manually clicking through menus — for teams that need to pre-configure plugins as part of CI or automated deployment scripts, this removes a step that previously could only be done by hand.
If your team uses a plugin that has both user settings and a bundled MCP server, the first thing to check after installing it is whether both entry points need to be filled in — don't assume everything is ready just because the plugin shows "Active now," especially if the install summary includes wording like "needs configuration before it can start," which signals a remaining step. Working claude plugin configure into your team's plugin deployment scripts turns this step into something repeatable and version-controllable, rather than relying on each person remembering to open the panel manually.