server: stdio MCP child processes not terminated on service restart / config reload #50758

Activity

1. github-actions

   assigned

   jlongster

   on Sep 22, 2026
2. github-actions commented on Sep 22, 2026

   

   github-actionsBot

   on Sep 22, 2026 – with GitHub Actions

   Contributor

   More actions

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

   • service: restart leaves stale daemon and duplicated MCP servers running #42270: "service: restart leaves stale daemon and duplicated MCP servers running" — very closely related: service restart also fails to terminate the old daemon's MCP child processes, leaving stale processes running alongside the new generation.
   • Local MCP disconnect leaves descendant processes running #46253: "Local MCP disconnect leaves descendant processes running" — overlapping root cause: MCP disconnect/teardown paths leave descendant processes alive.
   • mcp: orphaned local MCP server processes accumulate after sessions end #50363: "mcp: orphaned local MCP server processes accumulate after sessions end" — same symptom (orphaned stdio MCP processes accumulating), different trigger (session end vs. restart/config reload).
   • serve: per-request instances are never disposed - MCP child processes accumulate until memory exhaustion #47727: "serve: per-request instances are never disposed - MCP child processes accumulate until memory exhaustion" — same class of issue (MCP child process accumulation), different trigger (per-request instances).

   If this covers a distinct scenario (specifically config-reload-triggered restarts cascading under CPU contention), it may still warrant its own tracking, but please review the above issues first to see if your report fits better there or can be consolidated.
3. Tyxiel commented on Sep 29, 2026

   

   Tyxiel

   on Sep 29, 2026

   More actions

   Adding a data point that suggests a second trigger beyond restart/config-reload, and it may be the more important one.

   In my case none of the triggers in the original report happened: no opencode service restart, no config change, no MCP entry edited. The app was simply left open, and the server reconnected the same MCP server on its own every 3–5 minutes.

   Reconnect timestamps, last 12, all from a single server instance (run=4482db38):

   10:44:35  10:46:04  10:48:48  11:08:10  11:12:00  11:25:08
   11:25:59  11:30:10  11:33:07  11:33:31  11:35:11  11:35:17
   

   And the accounting over the whole log:

   mcp connected server=codegraph : 132
   mcp disconnected               :   2
   

   ~66 reconnects per disconnect. I searched the log for mcp disconnected, mcp closed, dispose, and cleanup — there is no per-connection teardown path, so each reconnect leaves a full 4-process tree (cmd.exe → node → node --liftoff-only → watchdog node) behind with its parent still alive.

   Measured growth over 8 minutes with no user action: 1.478 GB / 16 processes → 2.811 GB / 30 processes, roughly 370 MB per reconnect.

   Possible causal chain — the reconnect may not be the root cause but a symptom. The codegraph CLI ships a self-watchdog whose command line contains:

   function kill(extra) { /* "Main thread unresponsive for ~Ns" */ process.kill(parentPid, 'SIGKILL'); }

   with timeoutMs=60000 and capMs=600000. So the main codegraph thread is being detected as wedged, the watchdog kills it, and opencode reconnects — then fails to dispose the dead tree.

   If that holds, the missing dispose is still the thing to fix here, but there may be a companion fix needed so the watchdog death is handled as a clean shutdown rather than triggering a reconnect that stacks a new tree.

   Related: #46174 (Windows, multi-GB, same shape) — I have the fuller process census and the 132-vs-2 connect/disconnect accounting there.
4. neriousy

   marked server: no SIGTERM handling, MCP stdio (docker) children orphaned on every stop/restart #50780 as a duplicate of this issue on Oct 20, 2026
5. rekram1-node

   closed this as completedin #58351on Oct 23, 2026