Skip to content

mcp: mcp list reports failed while API reports connected after server reconnect #50725

New issue
New issue
Closed as not planned
Closed as not planned
mcp: mcp list reports failed while API reports connected after server reconnect#50725
Assignees
kitlangton

Description

@msamesch
msamesch
opened on Sep 22, 2026

Related to #36623 (closed as completed, Jul 14) — but the inverse mismatch with a different trigger: after a server reconnect, opencode mcp list reports failed: Connection closed while GET /api/mcp reports connected, and already-running session catalogs don't refresh after POST /api/experimental/mcp/<name>/connect. The session-catalog half still reproduces today.

Summary

After a local MCP server's connection drops mid-session (server process was up while its backend was down), reconnecting succeeds at the service level — mcp connected server=... tools=152 is logged — but opencode mcp list keeps reporting failed: Connection closed while GET /api/mcp reports connected, and a running session never receives the server's tools.

Environment

  • opencode version: v2.0.13
  • OS: Linux 6.1.0-53-amd64 (linux x64)
  • Terminal: TERM=xterm-256color, COLORTERM=truecolor
  • Shell: /bin/bash
  • Install/channel: latest
  • Active plugins: none found in config

Reproduction

  1. Configure a local MCP server in the global config (used: uv tool run --from git+https://github.com/... --with 'mcp<2' freecad-mcp with environment: {FREECAD_MODE: xmlrpc, FREECAD_XMLRPC_PORT: "9875"}).
  2. Start a session — server connects, tools appear in the catalog.
  3. Kill the backend the server depends on (FreeCAD bridge on port 9875) so the connection closes while the session is running.
  4. Restart the backend, then POST /api/experimental/mcp/<server>/connect — log shows mcp connected server=freecad tools=152.
  5. Compare status views, then check the running session.

Expected Behavior

  • opencode mcp list and GET /api/mcp agree on the server status.
  • After a successful service-level reconnect, running sessions either receive the server's tools, or there is a documented way to refresh them in-session.

Actual Behavior

  • opencode mcp list → ✗ freecad failed: Connection closed
  • GET /api/mcp → {"name":"freecad","status":{"status":"connected"}} (same moment)
  • Log confirms repeated successes after the failure: 
    level=WARN message="mcp connect failed" server=freecad status.error="Connection closed"
level=INFO message="mcp connected" server=freecad tools=152 connectionID=9ecf...
level=INFO message="mcp connected" server=freecad tools=152 connectionID=0ca0...
level=INFO message="mcp connected" server=freecad tools=152 connectionID=523f...
  • The running session's tool catalog still contains 0 tools for the server namespace (search({namespace:"freecad"}) → empty) even after the logged reconnects.
  • Each connect call creates a new connectionID; the session's original connection (the one that failed) appears never to be revived.

Additional Context

  • Frequency: consistent — 3 reconnect attempts, same split-brain status each time.
  • The MCP server process itself is healthy: a manual stdio handshake (initialize → tools/list) succeeds outside OpenCode.
  • Logs show directory=/home/<user> on the MCP entries while the session workspace is a subdirectory of it — possibly relevant to which status is authoritative.
  • Workaround that resolves it: starting a new session (picks up the connected service-level server on startup).
  • /mcps was attempted but arrived as plain text in this client rather than opening the panel, so in-session reconnect couldn't be tested.

Activity

  1. github-actions
    assigned
    kitlangton
    on Sep 22, 2026

  2. github-actions commented on Sep 22, 2026

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

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

    The split-brain status between opencode mcp list and GET /api/mcp appears to be a distinct angle not covered by those issues, so this may still warrant a separate report.

  3. msamesch commented on Sep 22, 2026

    @msamesch
    msamesch
    on Sep 22, 2026
    Author

    catalog eventually populated later in the session; split-brain status from mcp list vs API persists

  4. opencodejr commented on Oct 28, 2026

    @opencodejr
    opencodejrBot
    on Oct 28, 2026
    Contributor

    Thanks for the detailed report. I tried this on v2.0.13 with a local stdio MCP server that I could kill mid-session, and I think both symptoms come from MCP state being kept per directory, not from a broken reconnect.

    • opencode mcp list asks the service about the directory you run it from. opencode api … sends no directory, so the service uses your home directory. Your logs show directory=/home/<user> on the MCP entries, which fits this.
    • So opencode api POST /api/experimental/mcp/freecad/connect, run without a directory, reconnects the server for /home/<user>. The copy for your session's workspace subdirectory stays failed: Connection closed. I got exactly your split this way: GET /api/mcp said connected while mcp list said failed.
    • When I sent the connect for the session's directory, mcp list went back to connected. My running session also got the server's tools back in its next model request: 
      opencode api POST /api/experimental/mcp/freecad/connect -H "x-opencode-directory:$PWD"
      Run this from the session's workspace directory.

    As far as I can tell, this is how per-directory state is designed to work, not a bug. If it still fails for you after a connect scoped to the session's directory, please reply with the output of opencode mcp list and opencode api GET /api/mcp -H "x-opencode-directory:$PWD", both run from that directory, and whether the session gets the tools on its next message.

    The real gap here is that OpenCode doesn't restart a local server on its own after its connection drops, so you have to reconnect by hand. That's tracked in #53226, and there's a fix in progress in #54378. If showing the reconnect directory in opencode api or the logs would have helped, a feature request for that might be worth filing.

  5. opencodejr
    closed this as not plannedon Oct 31, 2026

  6. opencodejr commented on Oct 31, 2026

    @opencodejr
    opencodejrBot
    on Oct 31, 2026
    Contributor

    We haven't heard back, so I'm closing this as not planned.

    When I tried this on v2.0.13, the split between opencode mcp list and GET /api/mcp came from MCP state being kept per directory. A connect sent without a directory went to your home directory's copy, while the session's workspace copy stayed failed. A connect scoped to the session's directory brought both the status and the session's tools back:

    opencode api POST /api/experimental/mcp/freecad/connect -H "x-opencode-directory:$PWD"

    The underlying gap, that a dropped local server isn't restarted on its own, is tracked in #53226, with a fix in progress in #54378.

    If it still fails for you after a connect scoped to the session's directory, please comment with the output of opencode mcp list and opencode api GET /api/mcp -H "x-opencode-directory:$PWD", both run from that directory, and we can reopen this. Thanks for the detailed report!

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