Skip to content

MCP servers that fail to connect are never retried and silently disappear from the tool list #51437

New issue
New issue
Closed as not planned
Closed as not planned
MCP servers that fail to connect are never retried and silently disappear from the tool list#51437
Assignees
rekram1-node
Labels
needs:complianceThis means the issue will auto-close after 2 hours.

Description

@Bruce-Yii
Bruce-Yii
opened on Sep 26, 2026

Summary

When a batch of MCP servers fails to connect during session startup, opencode never
retries them and reports nothing to the user. The servers silently disappear from the
agent's tool list for the rest of the session, even though the same servers connect
successfully moments later. The only symptom is "my tools vanished".

Steps to reproduce

  1. Configure several MCP servers (both type: "remote" HTTP servers and type: "local"
    stdio servers).
  2. Make them unreachable for a short window — e.g. suspend the process, block egress, or
    interrupt a proxy the servers depend on.
  3. Start a session.

Actual: every server fails to connect, the tool list is missing them, and nothing is
retried afterwards. A later session, or a different directory, connects successfully
against the same servers.

Expected: either retry with backoff, or surface a persistent and visible error state.

Log evidence

All servers connect normally at first:

mcp connected  server=linear      tools=68
mcp connected  server=brightdata  tools=5
mcp connected  server=playwright  tools=25
mcp connected  server=firecrawl   tools=27
mcp connected  server=github      tools=45
mcp connected  server=context7    tools=2
mcp connected  server=kimi-cu     tools=13

About three minutes later a cold-start burst fails across the board:

mcp http request failed  code=ConnectionRefused  durationMs=21043  origin=https://mcp.linear.app  method=POST
mcp connect failed      server=linear    "Unable to connect. Is the computer able to access the url?"
mcp http request failed  code=ConnectionRefused  durationMs=21048  origin=https://mcp.tavily.com  method=POST
mcp connect failed      server=tavily    "Unable to connect. Is the computer able to access the url?"
mcp http request failed  code=ConnectionRefused  durationMs=21038  origin=https://mcp.notion.com  method=POST
mcp connect failed      server=notion-remote
mcp http request failed  code=ConnectionRefused  durationMs=21046  origin=https://mcp.exa.ai  method=POST
mcp connect failed      server=exa
mcp connect failed      server=playwright  "Request timed out"
mcp connect failed      server=fetch       "Request timed out"
mcp connect failed      server=cloudflare  "Request timed out"

Twenty seconds later, a different connection context for the same server succeeds:

mcp connected  server=linear  tools=68

…and there are no further mcp log lines for the remainder of the session.

Two details worth calling out:

  • Every failure lands within a few hundred milliseconds of 21000, i.e. the client's fixed
    connect timeout rather than a per-server network error. The local stdio server that
    makes no outbound requests (kimi-cu) keeps working throughout.
  • New connection contexts (other directories / other sessions) succeed against the
    identical servers, so neither the servers nor the credentials are at fault.

The same host was verified reachable from the same machine at the same time, both directly
and through the local proxy, and an MCP initialize POST to several of the origins
returned 200 with a valid protocol handshake. So the network path was healthy; only
opencode's own connection attempt failed.

Impact

A transient network or proxy blip permanently removes every MCP tool from the running
session. The user sees tools disappear with no error, and the only recovery is starting a
new session or restarting the server. Because both the failure window and the recovery are
silent, this is very hard to attribute after the fact.

Suggested fix

  1. Keep retrying with backoff instead of latching the failure, or at least re-attempt on
    the next turn / next tool call.
  2. Surface the state in the TUI: a visible per-server disconnected/error indicator, so a
    missing tool is at least explainable.
  3. Consider staggering the startup connect burst. When many servers are dialled at once
    they all hit the same timeout window, which turns one bad moment into a total outage.

Activity

  1. github-actions
    assigned
    rekram1-node
    on Sep 26, 2026
  2. github-actions
    added
    needs:complianceThis means the issue will auto-close after 2 hours.
    on Sep 26, 2026

  3. github-actions commented on Sep 26, 2026

    @github-actions
    github-actionsBot
    on Sep 26, 2026 – with GitHub Actions
    Contributor

    This issue doesn't fully meet our contributing guidelines.

    What needs to be fixed:

    • Please use the Bug Report template and provide the report in its required Description field; the current body uses a Summary heading instead.
    • Add system information, including the OpenCode version and operating system/runtime where this occurs.

    Please edit this issue to address the above within 2 hours, or it will be automatically closed.

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

    If you believe this was flagged incorrectly, please let a maintainer know.

  4. Bruce-Yii commented on Sep 26, 2026

    @Bruce-Yii
    Bruce-Yii
    on Sep 26, 2026
    Author

    Closing as a duplicate — this is already tracked, and my earlier duplicate search missed it.

    Tracked by:

    So the ask (add transport-level retry, surface a per-server error state) is unchanged and already on record. No reason to carry a fifth copy.

    What is possibly new here, for whoever picks up #25287

    The trigger in my report was neither a cold start nor a self-upgrade — it was a transient network/proxy interruption during session start, with the process otherwise healthy. Two observations that differ from the cold-start-race framing:

    1. The network was verifiably fine at the same moment. During and after the failure window I made a real MCP initialize POST to the failing origins and got 200 with a valid protocol handshake (context7, tavily, firecrawl), plus plain GETs returning 401/405 as expected for unauthenticated requests. Direct connections and connections through the local HTTP proxy both worked. So the failure was inside opencode's own connect attempt, not the path to those hosts.

    2. A different connection context succeeded ~20s later against the identical servers with no config or credential change, and the servers were then fine for the rest of that process's life. That points at a per-connection-context latch rather than a persistent bad state.

    3. Every failure landed within a few hundred ms of a 21000ms budget, across all remote servers simultaneously — a shared timeout boundary rather than per-server errors.

    Corrections to my own report

    • It used a free-form ## Summary heading instead of the Bug Report template, and omitted version/OS. Should have followed the template; the compliance bot was right.
    • My duplicate check (gh issue list --search "mcp reconnect" and three other queries) returned zero hits even though MCP servers fail to connect when a session starts during self-upgrade #44291's title contains "reconnect". That search was not reliable and I should have widened it.

    Environment

    • OpenCode server v2.0.16, running as a sidecar spawned by the desktop host
    • Windows 11 x64, build 22621
    • 11 MCP servers: 7 type: "remote", 4 type: "local" stdio (npx -y / uvx, plus one local binary)
  5. Bruce-Yii
    closed this as not plannedon Sep 26, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

needs:complianceThis means the issue will auto-close after 2 hours.

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions