feat(tui): explore a more capable MCP modal #36303

Activity

1. kitlangton

   self-assigned this

   on Jul 10, 2026
2. big-andy-coates commented on Aug 19, 2026

   

   big-andy-coates

   on Aug 19, 2026

   More actions

   Hey @kitlangton, +1 for being to re-authenticate mcp servers from within an active session :)
3. zhiganov commented on Sep 15, 2026

   

   zhiganov

   on Sep 15, 2026

   More actions

   Reproduction evidence: optional OAuth server appears connected but cannot authenticate in the TUI

   Environment

   • OpenCode: v2.0.3
   • OS: Windows 11 10.0.26200.9445
   • Terminal: Windows Terminal, TERM=xterm-256color
   • Shell: C:\WINDOWS\system32\cmd.exe
   • Install: npm global, latest channel
   • Active plugins: none found

   Reproduction

   • Configure an OAuth-capable remote MCP server that also exposes public tools.
   • Start OpenCode without stored OAuth credentials.
   • opencode mcp list and /mcps report the server as connected because anonymous initialization and public tools succeed.
   • Call an account-protected tool; it returns Unauthorized.
   • Open /mcps. The server can only be connected or disconnected with Space. Enter exposes no detail view or Authenticate action.
   • Run opencode mcp auth <server> externally and complete browser authorization.
   • Call the same protected tool again; it succeeds.

   Expected behavior

   The MCP modal should expose Authenticate/Re-authenticate for OAuth-capable remote servers even when their transport status is connected. Alternatively, a protected-tool authorization failure should transition the server to an actionable authentication-required state.

   Actual behavior

   Anonymous connectivity masks the missing OAuth session. The TUI reports connected and offers no authentication path, leaving opencode mcp auth <server> as the only working route.

   This reproduces consistently with Avails. It is also the same detection ambiguity noted in #26195: an MCP server can return HTTP 200 without authentication while protected operations still require OAuth.
4. ggbdpq commented on Oct 4, 2026

   

   ggbdpq

   on Oct 4, 2026

   More actions

   Context: I opened #53065 proposing an MCP observability surface before finding this exploration (and #34435, closed as completed). This is the right design track, so consolidating — closing mine with a pointer.

   What I can usefully contribute to the "decide what users need to understand at a glance" checklist is failure-mode evidence: there are 10+ open MCP lifecycle issues whose diagnosis is blocked by exactly the facts a panel could surface:

   • Failed/pending servers need a "why": mcp: remote MCP servers that fail once are never retried until service restart #52237 (remote servers never retried after one failure), mcp: no reconnect after network change/socket reset; stale Error until server process is killed #52564 (stale error persists after network change) — a per-server last error + timestamp would make both diagnosable in place. mcp: mcp list reports failed while API reports connected after server reconnect #50725 (mcp list says failed while the API says connected) is the same gap seen from the other side: two surfaces reading different state.
   • Connected servers need "what is this holding": MCP: local servers are spawned per session and never released when a session ends #51249, mcp: orphaned local MCP server processes accumulate after sessions end #50363, Duplicate MCP servers accumulate under one opencode process (5× mcp-reva, ~6GB RAM) #52965, MCP child-process leak: server never reaps MCP children per (re)connection, leading to unbounded memory growth #52410, Local MCP disconnect leaves descendant processes running #46253, serve: per-request instances are never disposed - MCP child processes accumulate until memory exhaustion #47727 are all process-accumulation bugs. A stdio server row showing pid + child-process count + uptime turns "sessions got slow — is MCP leaking again?" into a glance instead of a pgrep session.
   • Disabled/registration-required need "what changed": mcp: initial reconciliation can duplicate stdio servers #52741 (duplicate stdio servers after reconciliation) is currently only observable as behavior, not as state.

   Concrete data suggestion: the service already tracks per-server status internally; extending the status payload with transport type, pid, child-process count, uptime, and last error/time requires no new architecture and would give this modal a factual floor to design the states on. Happy to draft that status-payload extension as a PR if it's useful to the exploration.
5. VlexWest commented on Oct 17, 2026

   

   VlexWest

   on Oct 17, 2026

   More actions

   Opened #56452 for the enable/disable part: space in /mcps toggles a server in any state (failed & pending too) & saves it to the config file that defines it.