fix(mcp): MCP server loses connection mid-session causing intermittent failures

Pre-flight Checks

I have searched existing issues and this is not a duplicate
I understand this issue needs status:approved before a PR can be opened

Bug Description

The MCP server intermittently loses connection mid-session, causing multiple MCP tools to return "Not connected". This happens after the connection was successfully established and used.

Steps to Reproduce

Start an OpenCode session
Verify MCPs work (e.g., supabase_list_projects returns data)
Use multiple MCP calls over several minutes
Eventually, MCPs like Supabase, Desktop Commander, n8n, and Universal Brain return Not connected
Other MCPs with persistent connections (Telegram, MetaTrader 5) continue working

Expected Behavior

MCP connections should remain stable throughout the session, or auto-reconnect transparently.

Actual Behavior

Multiple MCPs simultaneously fail with Not connected:

supabase_list_projects → Not connected
desktop-commander_list_directory → Not connected
n8n_n8n_health_check → Not connected
universal-brain_ping → Not connected

Meanwhile, MCPs with their own persistent connections remain functional:

telegram-mcp_get_me → ✅ Works
metatrader_get_account_info → ✅ Works

Operating System

Windows 11

Agent / Client

OpenCode

Shell

PowerShell 5.1

Relevant Logs

# Initial connection established:
> supabase_list_projects
[
  {"name":"Signalyn","id":"sglwgnwidhzddnuwewps"},
  {"name":"alpha-forge-mt5","id":"wjnoiuliovtdngtgskeq"}
]

# Later in same session:
> supabase_list_projects
Not connected

> desktop-commander_list_directory
Not connected

Additional Context

The failure appears to be a session drop in the OpenCode MCP server, not individual MCP config issues
A previous memory entry confirms this happened before: "Restored and stabilized all MCPs after context compaction" (project: opencode-mcps)
Workaround: None found. Session must be restarted.

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

MCP server connection lost after context compaction — tools unavailable until new session #23556: MCP server connection lost after context compaction — tools unavailable until new session (same symptom: MCP tools lost mid-session, requires new session to restore; your additional context even mentions "Restored and stabilized all MCPs after context compaction")
Bug: MCP tools permanently lost mid-session after single transient listTools() failure — no retry, no reconnect #17099: MCP tools permanently lost mid-session after single transient listTools() failure — no retry, no reconnect (same symptom: multiple MCP clients simultaneously lose connection mid-session while others remain working; root cause analysis and fix suggestions already documented there)

If your issue is the same, please consider adding any additional details (e.g. Windows-specific behavior) as a comment on those existing issues rather than opening a new one.

fix(mcp): detect transport close and update status to failed

Root cause confirmed: MCP manager stops spawning, not server-side

I have 7 MCP servers configured via opencode.json, all wrapped with a transparent JSON-RPC proxy logger (keylogger-mcp-wrapper). This captures every spawn, every request, and every response to JSONL files in ~/.keylogger-mcp/proxy/<name>/.

Evidence: servers are healthy (zero errors, zero crashes)

  obsidian-semantic     status=ok      events=  5  errors=0  last=exit
  pencil                status=spawned events=  8  errors=0  last=spawned
  serena                status=spawned events= 20  errors=0  last=spawned
  tilth                 status=ok      events= 43  errors=0  last=exit
  token-diet            status=spawned events=  9  errors=0  last=spawned
  voice-toolkit         status=spawned events=  9  errors=0  last=spawned

Evidence: healthy spawn cycle (voice-toolkit)

  [11:35:39] START    pid=12291
  [11:35:39] SPAWNED  child_pid=12593
  [11:35:39] TX       initialize id=0
  [11:35:39] ERR      Logging to ~/.voice-toolkit/logs/server.log
  [11:35:39] ERR      voice-toolkit MCP server v1.28.0 starting
  [11:35:39] RX       id=0 result=yes
  [11:35:39] TX       notifications/initialized
  [11:35:39] TX       tools/list id=1
  [11:35:39] RX       id=1 result=yes

Evidence: servers work perfectly when called directly

$ echo '{"jsonrpc":"2.0","id":1,"method":"tools/call",...}' | voice-toolkit
{"jsonrpc": "2.0", "id": 1, "result": {...}, "isError": false}  # works

Evidence: OpenCode client returns "Not connected"

When calling voice-toolkit_voice_mode from within an OpenCode session, the result is "Not connected". The proxy logger records NO start/spawn event, proving OpenCode never even attempts to spawn the server.

Cross-server pattern (all 7 servers, same session timestamp)

Every server shows 1 spawn, 0 tool_calls — OpenCode spawned them all for initialization, got the tool lists, then never called any tools. The MCP manager silently stopped routing requests.

Timeline

  11:35  → All 7 servers spawned, initialized, tools listed (healthy)
  11:20  → Server spawned, crashed (since fixed: missing import)
  11:04  → Server spawned, crashed (since fixed: missing import)  
  10:51  → Server spawned, initialized, tools listed (healthy)

Impact

This makes MCP tools unreliable. Sometimes they work for a while, then all 7 servers go "Not connected" simultaneously. Restarting the OpenCode session temporarily fixes it, confirming it's a client-side state issue in the MCP manager.

Environment

OpenCode: 1.14.33 → 1.14.40 (both affected)
macOS: arm64 (Darwin)
All MCP servers: stdio transport, Python/Rust, zero external dependencies
Config: ~/.config/opencode/opencode.json, 7 local MCP servers

Diagnostic tool available

The keylogger-mcp-wrapper is open source (https://github.com/artificemachine/voice-toolkit — see docs/MCP_LOGGING_ARCHITECTURE.md). Any OpenCode user can wrap their MCP servers with it to get the same visibility: keylogger-mcp-wrapper --name myserver -- <server-command>.

fix(mcp): auto-reconnect when remote server session drops mid-convers…

Confirmed, any estimate of when this will be available? My autonomous agent, which depends on an MCP I built, is stopping because the MCP closes. In Claude, this error doesn't occur because it restarts the MCP whenever it closes for any reason.

To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.

Navigation Menu

Repository navigation

fix(mcp): MCP server loses connection mid-session causing intermittent failures #23997

Pre-flight Checks

Bug Description

Steps to Reproduce

Expected Behavior

Actual Behavior

Operating System

Agent / Client

Shell

Relevant Logs

Additional Context

Root cause confirmed: MCP manager stops spawning, not server-side

Evidence: servers are healthy (zero errors, zero crashes)

Evidence: healthy spawn cycle (voice-toolkit)

Evidence: servers work perfectly when called directly

Evidence: OpenCode client returns "Not connected"

Cross-server pattern (all 7 servers, same session timestamp)

Timeline

Impact

Environment

Diagnostic tool available

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

fix(mcp): MCP server loses connection mid-session causing intermittent failures #23997

Description

Pre-flight Checks

Bug Description

Steps to Reproduce

Expected Behavior

Actual Behavior

Operating System

Agent / Client

Shell

Relevant Logs

Additional Context

Activity

github-actions commented on Apr 23, 2026

celstnblacc commented on May 7, 2026

Root cause confirmed: MCP manager stops spawning, not server-side

Evidence: servers are healthy (zero errors, zero crashes)

Evidence: healthy spawn cycle (voice-toolkit)

Evidence: servers work perfectly when called directly

Evidence: OpenCode client returns "Not connected"

Cross-server pattern (all 7 servers, same session timestamp)

Timeline

Impact

Environment

Diagnostic tool available

joseehilton147 commented on May 14, 2026

github-actions commented on Jul 14, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions