You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Local MCP disconnect leaves descendant processes running #46253
A local stdio MCP can spawn a wrapper process tree (npm exec, uvx, shell wrappers). Explicit disconnect and dynamic replacement call client.close(), which terminates the direct transport process but leaves its descendants running.
Full instance teardown already enumerates and terminates descendants, so cleanup behavior differs by lifecycle path. I reproduced this with a real stdio MCP fixture: before the fix, the parent exits and the child remains alive past the assertion deadline.
Expected: every MCP client ownership exit terminates the same full local process tree.
Related but distinct from #46035: that report currently shows complete MCP sets with live launchers, while this issue covers descendants left after teardown is invoked. Also related to the memory tracking thread #20695.
Plugins
None
OpenCode version
Current dev at dc4449df0d
Steps to reproduce
Configure a local stdio MCP whose launcher spawns a long-lived child process.
Connect it, then call MCP disconnect or replace the server under the same name.
Observe that the launcher exits while the child process remains alive.
Screenshot and/or share link
N/A; covered by a deterministic PID-based regression test.
Same behaviour on Windows with a real-world stdio MCP setup, and the surviving descendants are the whole problem.
Config: local MCP entries launched as ["npx","-y","@magicuidesign/mcp@latest"] etc. After some hours on OpenCode Desktop 2.0.11 / Windows 11, Get-CimInstance Win32_Process -Filter "Name='cmd.exe'" returned 81 live processes, all rooted at the single opencode-cli.exe serve --service instance. The launcher chain per server is:
client.close() terminates the direct transport child, but the outer cmd.exe /d /s /c "npx ..." and the package's own cmd.exe both stay alive, so the wrapper tree outlives the disconnect exactly as you describe. Grouping the 81 by direct parent confirms it: 45 are children of opencode-cli.exe, 34 are children of npx-cli.js nodes — i.e. both layers are orphaned, not just the innermost one.
On Linux this is invisible; on Windows each surviving cmd.exe is a console process that keeps a window on screen. So as a user-visible symptom this is not a brief flash but dozens of persistent cmd.exe windows accumulating over a session. Reproduced on 2.0.11, and earlier on 2.0.10.
It would help a lot if teardown enumerated and killed the whole tree on every ownership exit path (disconnect, replace, instance disposal), not only on full-instance teardown.
Activity
PVLPM commentedon Sep 20, 2026
Same behaviour on Windows with a real-world stdio MCP setup, and the surviving descendants are the whole problem.
Config: local MCP entries launched as
["npx","-y","@magicuidesign/mcp@latest"]etc. After some hours on OpenCode Desktop 2.0.11 / Windows 11,Get-CimInstance Win32_Process -Filter "Name='cmd.exe'"returned 81 live processes, all rooted at the singleopencode-cli.exe serve --serviceinstance. The launcher chain per server is:client.close()terminates the direct transport child, but the outercmd.exe /d /s /c "npx ..."and the package's owncmd.exeboth stay alive, so the wrapper tree outlives the disconnect exactly as you describe. Grouping the 81 by direct parent confirms it: 45 are children ofopencode-cli.exe, 34 are children ofnpx-cli.jsnodes — i.e. both layers are orphaned, not just the innermost one.On Linux this is invisible; on Windows each surviving
cmd.exeis a console process that keeps a window on screen. So as a user-visible symptom this is not a brief flash but dozens of persistentcmd.exewindows accumulating over a session. Reproduced on2.0.11, and earlier on2.0.10.It would help a lot if teardown enumerated and killed the whole tree on every ownership exit path (disconnect, replace, instance disposal), not only on full-instance teardown.