You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
MCP client connection status goes stale after initial connect #25682
Once an MCP server connects successfully, opencode never checks whether the connection is still alive. The status stays connected indefinitely, even when the underlying
connection is broken.
This means:
GET /mcp returns stale {"status": "connected"} for dead servers
Tool calls fail at invocation time with no prior warning
SSE /event has no mechanism to notify clients of a status change
There is no way to detect the problem externally without reconnecting every server on a timer
The only existing detection is ToolListChangedNotification in watch() (src/mcp/index.ts:460), which only fires when the server proactively sends a notification — it cannot
detect silent connection failures like a crashed process, a restarted remote server, or a network interruption.
This is especially problematic for users running opencode serve. The TUI has a human in the loop who can notice failures and restart, but serve mode is headless — typically
consumed by other tools or services via the HTTP API. When an MCP connection silently breaks in this mode, the server continues accepting requests and reporting everything as
healthy. There is no automatic reconnection, and no status change event for consumers to react to. The only external workaround is periodically calling POST /mcp/:name/connect
for every configured server, which tears down and rebuilds the connection each time — wasteful and disruptive
Closing as duplicate of #25287, which is the canonical tracker for remote MCP transport recovery. #32084 fixed stale status/tools after an actual client close; the remaining work is a bounded reconnect state machine for future requests, without blindly replaying a possibly executed tool call.
Activity
github-actions commentedon May 4, 2026
This issue might be a duplicate of existing issues. Please check:
Please review those issues and let us know if any of them already covers your report.
rekram1-node commentedon Jun 24, 2026
Closing as duplicate of #25287, which is the canonical tracker for remote MCP transport recovery. #32084 fixed stale status/tools after an actual client close; the remaining work is a bounded reconnect state machine for future requests, without blindly replaying a possibly executed tool call.