Repository navigation
cli: mcp list reports "Request timed out" for healthy, connected servers #52563
Description
Summary
opencode mcp list reports failed: Request timed out for 10/11 configured MCP servers, while the running server process has those same servers connected and healthy (verified via server log and live tool calls). The lister's standalone probing appears to time out on everything except instant local stdio servers.
Environment
- opencode version: 2.0.21
- OS: Darwin 25.2.0 (macOS, arm64)
- Terminal: Apple_Terminal, TERM=xterm-256color, COLORTERM=truecolor
- Shell: /bin/zsh
- Install/channel: latest (installed via https://opencode.ai/v2/install)
- Active plugins: one local file plugin auto-loaded from
~/.config/opencode/plugins/
Reproduction
- Configure several MCP servers in
~/.config/opencode/opencode.jsonc(mix of remote HTTP and localuvx/binary stdio servers). - Start the TUI; observe the server log:
mcp connected server=context7 tools=2,mcp connected server=gitmcp tools=5, plus localuvxservers connecting in 2–3s. - From another shell, run
opencode mcp list. - Optionally confirm reachability at the same moment:
curl https://mcp.context7.com/mcp→ HTTP 405 (~0.6s),curl https://gitmcp.io/docs→ 200.
Expected Behavior
mcp list reflects the live connection state (or at least completes an accurate probe): connected servers show connected, tool counts shown.
Actual Behavior
opencode mcp list output (11 configured servers; non-public server names redacted):
✗ context7 failed: Request timed out
✗ gitmcp failed: Request timed out
✗ <remote-https-3> failed: Request timed out
✗ <remote-https-4> failed: Request timed out
✗ <remote-https-5> failed: Request timed out
✗ <remote-https-6> failed: Request timed out
✗ <remote-https-7> failed: Request timed out
✗ <remote-sse-8> failed: Request timed out
✗ <local-uvx-1> failed: Request timed out
✗ <local-uvx-2> failed: Request timed out
✓ <local-binary-1> connected
Every remote server AND every uvx-based local server reports a timeout, while only an instant local stdio binary reports connected. At that same moment, the long-running server process (opencode serve --service) had 6 of these servers connected — public ones included (context7/gitmcp were reachable via curl from the same shell at the same moment).
--print-logs --log-level debug mcp list prints no log lines at all — only the status table — so the timeout cause is opaque. (--print-logs notes that server logs require --standalone.)
Additional Context
- The failures are uniform ("Request timed out") across HTTP-remotes and local
uvxspawns, suggesting a systemic issue in the lister's standalone connection path rather than per-server config. - Config was auto-migrated from v1 (
mcp.servers,disabled: falsenormalized) and parses cleanly (opencode debug configexit 0). - Reproducible: identical output across repeated runs minutes apart.
Activity
github-actions commentedon Oct 1, 2026
This issue might be a duplicate of existing issues. Please check:
opencode mcp listreports a server as failed while the API reports it connected after reconnecting, a similar mismatch between CLI status and live MCP server state.MusharrafSakran commentedon Oct 1, 2026
Related to #50725 but I believe distinct: in my case the mismatch is not tied to a reconnect event — every remote and uvx-based server reports "Request timed out" in
mcp listfrom a cold CLI invocation, while the long-running server process has them connected (server log showsmcp connected ... tools=N). Looks like the standalone lister probe path itself fails, not stale state. Both may share a root cause, but the repro here is 100% consistent without any reconnect involved.