mcp: local stdio servers exit(1) and never auto-reconnect on Windows

Summary

Local MCP servers (type: "local", spawned as node <script> with the stdio transport) connect successfully and then die minutes later with MCP server process exited with code 1 and no stderr. OpenCode never reconnects them, so they stay in failed state indefinitely — until the user edits the config file to force a respawn.

Environment

opencode version: v2.2.6 (channel: latest, global install)
OS: Windows 10.0.19045.6466 (win32 x64)
Terminal: Tabby (TERM_PROGRAM=Tabby, TERM=xterm-256color, COLORTERM=truecolor)
Shell: cmd.exe (COMSPEC), commands executed through Git bash
Install/channel: latest
Active plugins: local plugin files under %USERPROFILE%\.config\opencode\plugins\ (bash-alias/, token-tracker-realtime.js, usage-tracker/); no plugins field in opencode.json

Reproduction

Configure three local MCP servers, all spawned as node processes, for example:

{
  "mcp": {
    "servers": {
      "server-a": { "type": "local", "command": ["node", "C:\\path\\to\\a.mjs", "mcp"] },
      "server-b": { "type": "local", "command": ["node", "C:\\path\\to\\b.bundle.mjs"] },
      "server-c": { "type": "local", "command": ["node", "C:\\path\\to\\c-cli.js"] }
    }
  }
}

Start OpenCode. All servers connect (opencode mcp list → connected).
Leave the client idle (no tool calls). Between ~90 seconds and ~1 hour later, every node-based server process dies at the same moment.
opencode mcp list now reports:

✗ server-a    failed: Connection closed: MCP server process exited with code 1
✗ server-b    failed: Connection closed: MCP server process exited with code 1
✗ server-c    failed: Connection closed: MCP server process exited with code 1

The servers never reconnect on their own. Touching a server's config entry (saving opencode.json triggers config.updated) respawns it; opencode mcp list alone does not retry.

Expected Behavior

OpenCode should detect that a local MCP process exited and reconnect automatically (ideally with backoff), so the server status recovers without the user editing configuration.

Actual Behavior

All node-based local servers die simultaneously and silently (exit code 1, no stderr, no crash in Windows Event Viewer) and remain permanently failed. No reconnect attempt is logged.

Observed deaths within one session (server-side log, role=server):

message="mcp transport error" server=server-a error="MCP server process exited with code 1"
message="mcp transport error" server=server-b error="MCP server process exited with code 1"
message="mcp transport error" server=server-c error="MCP server process exited with code 1"

Additional Context

A diagnostic wrapper process was placed between OpenCode and each server to record stdin EOF, stdout/stderr EPIPE, child exit code and child stderr. It logged nothing unusual before death (no stdin end, no pipe error, no child error): the processes were terminated from outside, not crashed. When the config was later edited, the same wrapper recorded a clean teardown — STDIN END (parent closed stdin) → CHILD EXIT code=0 — confirming the silent exit-1 deaths are a different path from the graceful reconnect.
Deaths occur for every directory's connection at the same instant. A remote server (type: "remote") and one native (non-node) local server keep their connections across the same events, so the killer appears to target the node-based stdio children specifically.
Windows Event Viewer shows no Application Error/Application Hang entries for node.exe at the death timestamps.
Workaround that helps: save a change in opencode.json (any edit to the affected server entry forces a respawn). Only the server entries whose config value changed are respawned; unchanged entries stay failed.
Server processes run as children of opencode.exe serve --service.
Frequency: intermittent; 4 death events in ~3 hours of interactive use, ~1 minute to ~1 hour after connecting.

@enzoayala32

Thanks for the detailed report and the wrapper diagnostics, @enzoayala32!

I think this is a duplicate of #53226. That issue reports the same thing: a connected local stdio MCP server's process exits unexpectedly (often killed from outside OpenCode), OpenCode logs one mcp transport error, and the server stays failed until a config write respawns it. Comments there also describe every per-directory connection dying at the same moment, and mcp list showing the cached status instead of retrying.

Possible duplicates and related issues, ordered from most to least likely:

mcp: local server not restarted after transport error #53226: local stdio MCP server not restarted after a transport error (Windows, node servers, config edit as the only way to recover).
fix(mcp): reconnect dropped servers with backoff #54378: open PR that reconnects dropped MCP servers with backoff, local stdio servers included.
feat(core): keep MCP tools after a dropped connection and reconnect on demand #62756: open PR that keeps an MCP server's tools after its connection drops and reconnects it the next time it's used.
Windows: processes started by a tool command outlive the command and the server #57813: on Windows, processes started by a tool command outlive the command and the server. Might be related to what is killing the node processes.
desktop: supervisor respawns a live local service every ~60s (reason: 'missing'), aborting every tool call #61061: the desktop supervisor respawns the local service every ~60s. Might be related if you also run the desktop app.

Until that is fixed, #53226 has a workaround that doesn't involve editing the config. It reconnects one directory's connection:

opencode api post '/api/experimental/mcp/<server>/connect?location[directory]=<dir>'

The bot will close this issue as a duplicate in 1 day unless you reply explaining how your problem is different. If you find out what is killing the node processes, a comment on #53226 would help.

Thanks for the triage — confirmed as a duplicate of #53226, no need to keep this open.

I have added my wrapper-diagnostics evidence there: #53226 (comment) — the short version is that the node children die with no stdin/pipe/stderr activity (external kill, not a crash), a Rust .exe server survived the same events, and the clean exit code 0 teardown on config reload is a separate path.

The /api/experimental/mcp/<server>/connect workaround noted here is better than the config-edit one from my report — noted for future use. Subscribing to #54378 for the reconnect-with-backoff fix.

@enzoayala32

Thanks for confirming, @enzoayala32, and for adding the wrapper diagnostics to #53226. Having that evidence on the main issue is useful: the node children were killed from outside with no stdin, pipe or stderr activity, a native .exe server survived the same events, and the config-reload teardown takes a separate exit-0 path.

This issue will be closed as a duplicate of #53226 as planned. Following #53226 and #54378 is the best way to see progress on reconnecting.

@enzoayala32

Closing this as a duplicate of #53226, as agreed. Thanks again, @enzoayala32, for the wrapper diagnostics, and for adding them to #53226. Please follow #53226 for the underlying problem and #54378 for the reconnect-with-backoff change. Until then, opencode api post '/api/experimental/mcp/<server>/connect?location[directory]=<dir>' reconnects one directory's connection without editing the config.

Navigation Menu

Repository navigation

mcp: local stdio servers exit(1) and never auto-reconnect on Windows #62841

Summary

Environment

Reproduction

Expected Behavior

Actual Behavior

Additional Context

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

mcp: local stdio servers exit(1) and never auto-reconnect on Windows #62841

Description

Summary

Environment

Reproduction

Expected Behavior

Actual Behavior

Additional Context

Activity

opencodejr commented on Nov 9, 2026

enzoayala32 commented on Nov 9, 2026

opencodejr commented on Nov 9, 2026

opencodejr commented on Nov 10, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions