mcp: failed-at-init servers are never retried for the session lifetime #61105

Summary

Remote MCP servers that fail to connect during session init (e.g. Request timed out while the machine's network is briefly down) are marked failed and never retried for the lifetime of that session — even hours after connectivity returns. Only a NEW session (or a substantive config edit to the mcp section, see workaround) recovers them. opencode mcp list reports the persisted failed state rather than probing, so it also keeps showing failed after the network recovers.

Environment

• opencode version: 2.2.3
• OS: macOS (Darwin 25.6.0), arm64
• Terminal: Apple_Terminal, TERM=xterm-256color
• Shell: /bin/zsh
• Install/channel: release (homebrew stable, bottled 2.2.3)
• Active plugins: none found

Reproduction

1. Configure remote MCP servers (any type: remote, enabled: true; content-agnostic — all three remote servers in this setup reproduced it).
2. Stall outbound TCP during session init. Reproduced by waking the laptop from deep idle sleep while a VPN client's tunnel (default-route capture) was still reconnecting; all remote endpoints time out.
3. At the failing init, the log records mcp connect failed ... status.error="Request timed out" http.span≈30000 for every server.
4. Connectivity returns: a direct curl MCP initialize to the same endpoints returns 200, and NEW sessions in the same running server connect all servers fine (connect is per-session at init).
5. Keep using the original session for hours — no MCP tools ever appear, no retry is attempted, and opencode mcp list keeps showing failed.

Expected Behavior

Failed-at-init MCP servers are retried at some later point (next user message, config-change event, or an explicit reconnect verb) so that a transient network stall during startup does not silently cost the session all of its MCP tools.

Actual Behavior

No retry for the session lifetime. The log shows only the original failed attempts; the session stays without MCP tools until a new session is opened. opencode mcp list prints the persisted failure state without live-probing, which masks the fact that the endpoints are healthy again.

Additional Context

• Frequency: recurring — 30+ mcp connect failed events logged on this machine since 2026-10-07, in four classes: uniform ~30 s all-remote timeouts around sleep/wake; transient DNS ENOTFOUND pairs on cloud endpoints; sub-second ECONNRESET clusters; and one server-specific connect-hang class under server-side maintenance.
• Verified workaround (possibly useful for engineering): the config watcher diffs the mcp section per server and re-inits servers whose block changed — toggling a failing server's "enabled" from true to false and back reconnected it in the already-running, frozen session (log: mcp connected server=oam-graph tools=10, no restart of opencode needed). A config touch that does not change the mcp section triggers no re-init. It would help if this were documented or exposed as a supported reconnect path (e.g. a /mcps action or CLI verb).
• Sensitive values (API keys, endpoint URLs) redacted from all snippets.