[FEATURE] Support `default` field in plugin `userConfig` entries

Status Closed — not planned
Maintainer reply None cached
Activity 5 comments · opened Apr 11, 2026 · closed May 26, 2026

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 default is 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 default exists, the default is used
  • If no default is specified, current behavior is unchanged (user must provide a value)
  • ${user_config.KEY} substitution and CLAUDE_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_

View original on GitHub ↗

5 Comments

norrietaylor · 6 months ago

+1 — hit this today on a plugin that uses \${user_config.<key>} in an HTTP-type MCP server's url field, 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\:

  • No prompt appears at install or enable time (related to #39455)
  • MCP server fails to load: \Plugin MCP server error - generic-error: Plugin option \"distillery_mcp_url\" isn't set.\
  • The declared \default\ is neither prompted, prefilled, nor substituted when the value is unset

Docs 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.

k33bs · 5 months ago

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.

github-actions[bot] · 4 months ago

Closing for now — inactive for too long. Please open a new issue if this is still relevant.

k33bs · 4 months ago

not planned? its in the schema... lol
its just not implemented.

github-actions[bot] · 2 months ago

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.