[FEATURE] Support `default` field in plugin `userConfig` entries
Preflight Checklist
- [x] I have searched existing requests and this feature hasn't been requested yet
- [x] This is a single feature request (not multiple features)
Problem Statement
The userConfig field in plugin.json is the correct mechanism for prompting users to provide per-user configuration values when enabling a plugin. However, userConfig entries only support description and sensitive — there is no way to specify a default value.
This means that every userConfig key is effectively required: the user must provide a value at enable time, even when a sensible default would work for the majority of users. For plugins distributed via private organizational marketplaces, this creates unnecessary friction during onboarding, especially when most users would accept the same default.
Proposed Solution
Proposed Solution
Add an optional default field to userConfig entries:
{
"userConfig": {
"work_dir": {
"description": "Working directory for job outputs",
"default": "/scratch/orchestrate",
"sensitive": false
},
"container_dir": {
"description": "Path to Apptainer/Singularity container images",
"default": "/large_storage/ctc/public/apptainer",
"sensitive": false
},
"api_token": {
"description": "API authentication token",
"sensitive": true
}
}
}
Behavior
- When a
defaultis provided, the prompt at enable time pre-fills or displays the default, and the user can accept it by pressing Enter - If the user provides no value and a
defaultexists, the default is used - If no
defaultis specified, current behavior is unchanged (user must provide a value) ${user_config.KEY}substitution andCLAUDE_PLUGIN_OPTION_<KEY>export work the same regardless of whether the value came from user input or the default
Alternative Solutions
We maintain a private marketplace with plugins that launch MCP servers on a shared HPC cluster. Most users share common paths for container images and scratch directories, but some users need to override them. Today, every user must manually enter these values at enable time, even though the defaults would work for 90% of the team. A default field would let us ship sensible values while still allowing per-user customization.
Priority
Medium - Would be very helpful
Feature Category
CLI commands and flags
Use Case Example
_No response_
Additional Context
_No response_
5 Comments
+1 — hit this today on a plugin that uses
\${user_config.<key>}in an HTTP-type MCP server'surlfield, and wanted to record the empirical failure mode and a docs discrepancy for anyone landing here.Repro: plugin manifest declares
\
\\json\"userConfig": {
"distillery_mcp_url": {
"type": "string",
"default": "https://distillery-mcp.fly.dev/mcp"
}
},
"mcpServers": {
"distillery": {
"type": "http",
"url": "\${user_config.distillery_mcp_url}"
}
}
\
\After \
claude plugin install distillery\:Plugin MCP server error - generic-error: Plugin option \"distillery_mcp_url\" isn't set.\default\is neither prompted, prefilled, nor substituted when the value is unsetDocs discrepancy worth flagging: the current plugin reference at https://code.claude.com/docs/en/plugins-reference.md#user-configuration documents \
default\as a supported \userConfig\field (and even includes an HTTP MCP server example using \\${user_config.api_endpoint}\). The implementation clearly doesn't honor that contract yet, so the docs are ahead of reality here. Either landing this feature or correcting the docs would prevent plugin authors (myself included) from shipping installs that break for evaluators who accept the default.Why it matters for our case: the plugin ships a demo-first UX — evaluators hit the hosted URL with zero config, self-hosters override via plugin config. Without working defaults, evaluators get a broken plugin instead of a working demo. We had to revert to a hardcoded URL + \
claude mcp add --scope user\as the override path (distillery PR norrietaylor/distillery#331). Would love to come back to the clean \\${user_config.*}\pattern once this lands.adding to this that "Tab: Next field" currently jumps to the next top tab to marketplace instead of advancing to the next config field... big issues here. note that default values should also be still shown below input, grayed out etc.
including displaying min/max/required instructions if set.
Closing for now — inactive for too long. Please open a new issue if this is still relevant.
not planned? its in the schema... lol
its just not implemented.
This issue has been automatically locked since it was closed and has not had any activity for 7 days. If you're experiencing a similar issue, please file a new issue and reference this one if it's relevant.