Repository navigation
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.opencodejr commentedon Oct 28, 2026
Thanks for the detailed report. I tried to reproduce this on 2.0.21 and couldn't get the timeouts.
What I tried: a global
opencode.jsoncwithmcp.serverscontaining:context7(https://mcp.context7.com/mcp),gitmcp(https://gitmcp.io/docs) and several other HTTP remotesuvxcold starts)I ran
opencode mcp listrepeatedly from several project directories. Every server went frompendingtoconnectedwithin a few seconds, and none showedRequest timed out.In v2,
mcp listdoesn't probe servers itself. It asks the background service for the MCP status of the directory you run it in. The default startup and tool-listing timeouts are 30s, so a timeout on servers that normally start in 2–3s suggests something specific to your setup.These would help narrow it down:
timeoutvalues orexperimental.mcp_timeoutappear in your config, including what was migrated from v1? Small values there become the MCP request timeouts in v2. Themcpsection ofopencode debug configoutput would show this (redact URLs and headers as needed).opencode mcp liststill show the timeouts when run from the same directory as the running TUI session, and again after waiting ~30s?mcp connect failedlines (they includeserver=anddirectory=) for one of the failing public servers, e.g.context7, from the time you ranmcp list.HTTPS_PROXY) but not to your interactive shell.You can reply here, or edit the issue and leave a comment saying you've updated it.
Possibly related, not the same problem:
mcp listreports a server as failed while the API reports it connected, after a reconnectopencodejr commentedon Oct 31, 2026
Closing this as not planned for now. I couldn't reproduce
Request timed outfromopencode mcp liston 2.0.21. With context7, gitmcp, several other HTTP remotes and slow local stdio servers, every server went frompendingtoconnectedwithin a few seconds. I haven't heard back about the details that would narrow it down: anytimeout/experimental.mcp_timeoutvalues carried over from your v1 config, whether runningmcp listfrom the same directory as the TUI makes a difference, themcp connect failedlines from the service log, and any proxy settings that apply to the service process.If it still happens, reply with those details and we can reopen and take another look. Related reports you may want to follow: #50725, #48743, #52237.