[FEATURE]: MCP config - prompt for unresolved placeholder values and store the secrets outside the config #58653

Activity

1. opencode-agent commented on Oct 24, 2026

   

   opencode-agentBot

   on Oct 24, 2026 – with OpenCode Agent

   Contributor

   More actions

   Thanks for splitting this out of #58243 and for the clear write-up!

   To restate: when an mcp entry in the config has a placeholder that can't be resolved, you'd like OpenCode to ask you for the value once per variable, before any server starts. The answer would be stored outside the plaintext config (the OS keyring, or the credential store the OAuth flow already uses) instead of silently becoming an empty string. Today {env:VAR} is only filled from the process environment, and a missing variable becomes an empty string, as the docs say. So this is a feature request rather than a bug. Maintainers will consider it.

   Related issues you may want to follow:

   • [FEATURE]: MCP manager UX - per-server output links (web panel URLs), placeholder prompts with secure secret storage, a full config editor, and richer ask/mention inputs #58243: the parent MCP manager UX request
   • config: unresolved {env:VAR} silently becomes an empty string (remote MCP fails with an opaque 401) #53784 / mcp: {env:NAME} substitution in mcp.servers.*.environment resolves to empty #55229: an unset {env:} variable silently becoming an empty string (the opaque 401 you hit)
   • mcp: {env:...} in remote server headers not expanded (401 unauthorized) #56125: {env:} expansion in remote server headers
   • mcp: server error text can write config secrets into the local engine log #53051 / api: /api/model, /api/config and /api/provider/{id} return resolved provider credentials #53465: config secrets showing up in the engine log and in /api/config
   • mcp: invalid server entries are silently dropped from config #55419: invalid MCP entries silently dropped
   • feat(mcp): scoped server config, project approval, and keychain storage #44803: an earlier PR (closed, not merged) that tried keychain storage for MCP config

   This can't be done as a plugin today: plugins have no way to ask the user for input before the config is loaded and servers start, and no access to a protected secret store.
2. Dante-dan commented on Oct 24, 2026

   

   Dante-dan

   on Oct 24, 2026

   Contributor

   More actions

   I'd propose a bounded first version for unresolved MCP {env:VAR} references:

   • Keep process environment values first. Only a missing value enters the credential-reference flow; an explicitly supplied environment value is never overwritten by a stored value.
   • During an explicit interactive config adoption/add/edit action, collect unresolved variable names before starting affected servers and ask once per distinct variable. Cancelling leaves that server disconnected and its prior config intact. No prompt during background reload or headless/server startup: return an actionable missing-secret error naming the variable and server, without making an empty-credential connection attempt.
   • Store an entered value outside the config in a protected credential backend. Keep only a non-secret reference in JSON(C), scoped so unrelated projects cannot silently consume each other's credentials. Prefer an OS credential backend where available; if extending the existing integration credential store as a first phase, make that choice explicit rather than silently falling back to plaintext config. Replacement and removal need explicit lifecycle actions; deleting one reference must not erase a shared secret still in use.
   • Preserve unresolved references as references in config responses. Redact resolved values from API/config output, logs and connection errors, including values echoed back in server errors (mcp: server error text can write config secrets into the local engine log #53051 / api: /api/model, /api/config and /api/provider/{id} return resolved provider credentials #53465). A secret prompt never echoes the entered token.

   The current variable resolver substitutes missing environment values with an empty string. The existing Credential.Service is keyed by integration ID and stores integration credentials in the database; it is not an existing arbitrary MCP-placeholder keyring flow. This proposal therefore needs an explicit MCP credential namespace/reference mapping and a decision on protection/backend guarantees. #44803 is historical reference for keychain work, but it was closed without merging; I would not assume that backend exists in dev.

   Planned acceptance checks: environment-over-store precedence; one prompt for repeated references; no prompt or network attempt on a headless missing secret; cancellation/reload/restart; credential replacement and shared-reference deletion; unavailable-store failure; no literal secret in saved config, API responses or error/log output. Other tools' ${env:VAR} / ${VAR} syntax would require an explicit import conversion rather than guessing during normal OpenCode parsing.

   Would you approve this first-phase design, including the credential backend and reference scope? This is a design proposal based on source inspection; these changes and checks are planned, not implemented or run.