mcp: local server not restarted after transport error

Summary

When a local (stdio) MCP server process exits unexpectedly while a session is already connected, OpenCode logs a single mcp transport error warning and never restarts it. The server's tools silently disappear from the agent's tool list for the remainder of the session. Only an unrelated event — a write to the OpenCode config file, or starting a new session — causes the server to be spawned again.

Environment

• opencode version: v2.0.22 (channel latest)
• OS: Windows_NT 10.0.26200.9550 (win32 x64)
• Terminal: Windows Terminal (WT_SESSION set), TERM=xterm-256color
• Shell: C:\WINDOWS\system32\cmd.exe
• Install/channel: latest (npm @opencode/cli)
• Active plugins: none configured in opencode.json

Reproduction

1. Configure a local stdio MCP server that stays alive after initialize, for example:

   {
     "mcp": {
       "servers": {
         "playwright": {
           "type": "local",
           "command": ["C:\\Program Files\\nodejs\\node.exe", "C:\\path\\to\\mcp\\cli.js"]
         }
       }
     }
   }
   

2. Have OpenCode sessions open in two or more directories, so several connections to the same server are spawned (one per directory).
3. Kill the MCP server process from outside OpenCode. A realistic trigger is another OpenCode session running a broad process cleanup such as:

   Get-Process node,msedge -ErrorAction SilentlyContinue |
     Where-Object { $_.StartTime -gt (Get-Date).AddMinutes(-25) } |
     ForEach-Object { try { $_.Kill() } catch {} }
   

   Any taskkill, service restart of a parent process, or OOM kill should behave the same way.
4. Observe that the MCP tools are no longer offered to the agent, and that nothing brings them back.

Expected Behavior

A local MCP server whose process exits unexpectedly should be restarted automatically (ideally with backoff and a cap on retries), so its tools remain available. At minimum, a crash while connected should be retried the same way an initial connect failure is.

Actual Behavior

One warning is logged per connection and then nothing:

timestamp=2026-10-04T20:48:21.035Z level=WARN message="mcp transport error" server=playwright error="MCP server process exited with code 255" role=server directory="<project-a>" connectionID=<id>
timestamp=2026-10-04T20:48:21.051Z level=WARN message="mcp transport error" server=playwright error="MCP server process exited with code 255" role=server directory="<project-b>" connectionID=<id>
timestamp=2026-10-04T20:48:21.067Z level=WARN message="mcp transport error" server=playwright error="MCP server process exited with code 255" role=server directory="<project-c>" connectionID=<id>
timestamp=2026-10-04T20:48:21.082Z level=WARN message="mcp transport error" server=playwright error="MCP server process exited with code 255" role=server directory="<project-d>" connectionID=<id>
timestamp=2026-10-04T20:48:21.099Z level=WARN message="mcp transport error" server=playwright error="MCP server process exited with code 255" role=server directory="<home>" connectionID=<id>

No mcp connected line follows, and no retry is attempted. The agent's tool list loses every tool from that server and does not recover on its own.

Notes on scope and contrast:

• The shared background service was not restarted during this occurrence (same PID and start time before and after), so this is specific to MCP child processes rather than a service restart.
• Retry-on-startup does appear to exist: an earlier mcp connect failed was followed by a successful mcp connected roughly 35 seconds later. What is missing is retry-on-crash for a server that was already connected.
• Writing to the global config file causes all connections to be torn down and respawned immediately (mcp connected ... tools=25 for every directory within ~2s), which currently works as an accidental recovery trigger.

Additional Context

• Frequency: 4 occurrences within roughly 40 minutes in one session. Always reproducible when the child process is killed.
• Exit code was 255 in every occurrence, consistent with an external kill rather than a crash inside the server. The MCP server itself worked correctly when spawned manually: initialize succeeded, tools/list returned 25 tools, and tools/call browser_navigate succeeded.
• An earlier, separate failure mode was also observed and is believed to be a different issue: when the command was npx -y <package>, several connections spawned at once raced on the package manager's shared install cache and died with ENOTEMPTY ... InstallFailed extracting tarball. Working around it by pre-installing the package and using an absolute path made startup reliable. Mentioned here only for context.
• Workarounds currently used: write to the global opencode.json to force a respawn, or opencode service restart. Both are indirect — the first mutates configuration as a side effect.
• Suggested direction (if this is a bug rather than intended behavior): treat mcp transport error like a failed connect and re-enter the spawn/retry path, ideally with exponential backoff and a cap so a permanently broken server does not spin.