Claude Code on the web: no way to supply plugin `userConfig` (secrets) to cloud sessions

Summary

Plugins that declare a userConfig field (e.g. an API token) have no supported way for an individual user to supply those values in Claude Code on the web (cloud sessions). Any plugin whose bundled .mcp.json server authenticates with ${user_config.<field>} silently 401s.

Why

• Cloud sessions load config only from the repo's committed .claude/; locally-installed plugins (~/.claude/plugins/) don't carry over.
• A plugin can auto-install via committed .claude/settings.json enabledPlugins.
• But plugin userConfig is read only from user/managed settings (a project's .claude/settings.json is ignored), and sensitive values live in the keychain / ~/.claude/.credentials.json — none of which exist in a fresh cloud VM, and there is no headless prompt. So ${user_config.token} substitutes empty → 401.

Compounding issue

If the same MCP service is also an OAuth connector on claude.ai (a common way to get the tools into cloud), the plugin's .mcp.json server points at the same URL. Per documented precedence (local > project > user > plugin > connector; same-endpoint = duplicate) the tokenless plugin server wins and hides the working connector. So enabling the plugin replaces a working connection with one that 401s. Users must choose commands (broken tools) or tools (no commands).

Repro

1. Plugin with .mcp.json HTTP server header Authorization: Bearer ${user_config.token} and userConfig.token (required, sensitive).
2. Add enabledPlugins (+ extraKnownMarketplaces) to a repo's committed .claude/settings.json.
3. Open a cloud (web) session on that repo.
4. Commands appear; the plugin MCP server returns 401 — no prompt, nowhere to supply the token. An OAuth connector for the same URL is now hidden.

Proposals (any one helps)

1. Let cloud sessions read userConfig from an account-scoped secret set once in the claude.ai UI, injected at startup like connectors.
2. Honor sensitive userConfig from a session/env secret for cloud/CI.
3. Don't let a userConfig-unsatisfied plugin MCP server shadow a connector — skip registering it (or drop below connectors) when ${user_config.*} is unresolved.
4. At minimum, emit a clear diagnostic instead of a bare 401 when a required userConfig is unresolved headlessly.