tui: MCP server dialogs show an empty list #36580

Activity

1. github-actions

   assigned

   kommander

   on Jul 13, 2026
2. opencode-agent

   added

   2.0

   on Jul 13, 2026
3. opencode-agent commented on Jul 13, 2026

   

   opencode-agentBot

   on Jul 13, 2026 – with OpenCode Agent

   Contributor

   More actions

   I traced both paths. The TUI does not derive this list from its loaded config; both dialogs render sync.data.mcp, populated by the SDK's GET /mcp call during non-blocking bootstrap. That call currently does not use throwOnError or inspect result.error:

   sdk.client.mcp.status({ workspace }).then((x) =>
     setStore("mcp", reconcile(x.data ?? {})),
   )

   So any fulfilled API error/missing data is converted to {}, after which the picker looks empty and Status says “No MCP Servers.” By contrast, opencode2 mcp list loads config/MCP state directly in its own process. This makes the leading hypotheses:

   1. /mcp is returning an error that the TUI masks as an empty successful response; or
   2. the TUI request and mcp list are resolving different directory/workspace/server contexts.

   Could you provide the following from the same project directory? Please redact server names, command arguments, paths, URLs, headers, and tokens as needed.

   1. Output (including HTTP/API error detail) of:

      opencode2 api get /mcp

   2. Whether this reproduces with:

      opencode2 --standalone

   3. The exact command used to start the TUI, and whether --server, --port, OPENCODE_SERVER, or experimental workspaces are involved.
   4. Relevant redacted role=cli and role=server log lines from one launch/reproduction, especially any tui bootstrap failed, /mcp, workspace-routing, or instance-loading errors.

   One subtlety: depending on this build/launch mode, the TUI may use an embedded worker/private server rather than the healthy service at 127.0.0.1:4096, so the health check alone does not establish that mcp list, api get /mcp, and the TUI share the same instance.

   The masking behavior is now tracked broadly in #36582, but the output above should identify the underlying failure for this report.
4. mwikala commented on Jul 13, 2026

   

   mwikala

   on Jul 13, 2026

   Author

   More actions

   The MCP servers are now appearing in the TUI. This may have been caused by the TUI or background service retaining stale state after the V1-to-V2 configuration migration; reloading the shell and restarting/reconnecting the service appears to have resolved it. I can no longer reproduce the original issue, so I’m closing this report.
5. mwikala

   closed this as completedon Jul 13, 2026
6. mwikala commented on Jul 13, 2026

   

   mwikala

   on Jul 13, 2026

   Author

   More actions

   Nevermind, I thought this was a one off but I keep seeing it happen. Sometimes I see my MCPs listed in the TUI, but more often they're not.

   At all times though, the MCPs are available to the agent. I do keep seeing it do a search though instead of just calling the MCP directly:

   
7. mwikala

   reopened this on Jul 13, 2026
8. entrptaher commented on Jul 14, 2026

   

   entrptaher

   on Jul 14, 2026

   Last edited by entrptaher

   More actions

   Facing same issue.

   

   Tried with cloning the v2 directly and running, no avail.
9. entrptaher commented on Jul 14, 2026

   

   entrptaher

   on Jul 14, 2026

   More actions

   I think I fixed the thing.

   

   The issue was that mcp.server.refresh() and mcp.resource.refresh() were passing locationQuery(ref) which returns undefined when called during bootstrap (no argument), instead of locationQuery(ref ?? defaultLocation()) like all other location refresh methods do.

   This caused MCP data to be stored under a key derived from the server's process.cwd() while DialogMcp reads from the key derived from the client's defaultLocation(), different keys, so nothing showed up.
10. opencode-agent commented on Jul 30, 2026

    

    opencode-agentBot

    on Jul 30, 2026 – with OpenCode Agent

    Contributor

    More actions

    Addressed by commit 2508a74 and the current location-scoped TUI data API. MCP server and resource sync now key both the request and store update from ref ?? defaultLocation(), using the authoritative location returned by the server; dialogs read from that same location key. This removes the bootstrap mismatch identified in the issue where MCP data was stored under process cwd but read under the client default location. Closing as resolved.
11. opencode-agent

    closed this as completedon Jul 30, 2026