Skip to content

cli: mcp list reports "Request timed out" for healthy, connected servers #52563

Closed as not planned

Description

@MusharrafSakran

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

Reproduction

  1. Configure several MCP servers in ~/.config/opencode/opencode.jsonc (mix of remote HTTP and local uvx/binary stdio servers).
  2. Start the TUI; observe the server log: mcp connected server=context7 tools=2, mcp connected server=gitmcp tools=5, plus local uvx servers connecting in 2–3s.
  3. From another shell, run opencode mcp list.
  4. 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 uvx spawns, 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: false normalized) and parses cleanly (opencode debug config exit 0).
  • Reproducible: identical output across repeated runs minutes apart.

Activity

  1. github-actions commented on Oct 1, 2026

    @github-actions
    Contributor

    This issue might be a duplicate of existing issues. Please check:

    • #50725: opencode mcp list reports a server as failed while the API reports it connected after reconnecting, a similar mismatch between CLI status and live MCP server state.
  2. MusharrafSakran commented on Oct 1, 2026

    @MusharrafSakran
    Author

    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 list from a cold CLI invocation, while the long-running server process has them connected (server log shows mcp 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.

  3. opencodejr commented on Oct 28, 2026

    @opencodejr
    Contributor

    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.jsonc with mcp.servers containing:

    • context7 (https://mcp.context7.com/mcp), gitmcp (https://gitmcp.io/docs) and several other HTTP remotes
    • two local stdio servers that take ~2.5s to start (standing in for uvx cold starts)
    • one instant local stdio server

    I ran opencode mcp list repeatedly from several project directories. Every server went from pending to connected within a few seconds, and none showed Request timed out.

    In v2, mcp list doesn'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:

    1. Timeout settings: do any timeout values or experimental.mcp_timeout appear in your config, including what was migrated from v1? Small values there become the MCP request timeouts in v2. The mcp section of opencode debug config output would show this (redact URLs and headers as needed).
    2. Same directory: does opencode mcp list still show the timeouts when run from the same directory as the running TUI session, and again after waiting ~30s?
    3. Service log: the mcp connect failed lines (they include server= and directory=) for one of the failing public servers, e.g. context7, from the time you ran mcp list.
    4. Proxy/VPN: anything that applies to the service process (e.g. 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:

  4. opencodejr commented on Oct 31, 2026

    @opencodejr
    Contributor

    Closing this as not planned for now. I couldn't reproduce Request timed out from opencode mcp list on 2.0.21. With context7, gitmcp, several other HTTP remotes and slow local stdio servers, every server went from pending to connected within a few seconds. I haven't heard back about the details that would narrow it down: any timeout / experimental.mcp_timeout values carried over from your v1 config, whether running mcp list from the same directory as the TUI makes a difference, the mcp connect failed lines 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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions