Repository navigation
Local MCP server processes spawned by the background service are not terminated when their owning client/session disconnects #57341
Description
Description
Local MCP server processes spawned by the background service are not terminated when their owning client/session disconnects. On every new opencode launch (TUI, opencode mcp list, …) a fresh stdio connection is created and a new server process is spawned; previous instances stay alive with their stdin pipe still open. Servers that bind a fixed TCP port (e.g. drawio-mcp-server with --extension-port and HTTP port 3000) then crash on the next launch with EADDRINUSE, so the MCP reports failed until the leftover process is killed manually.
Plugins
lgazo/drawio-mcp-server or other
OpenCode version
2.0.32
Steps to reproduce
- Configure a local MCP server that binds a fixed port, e.g.
"mcp": { "servers": { "drawio-server": { "type": "local", "command": ["node", "…/drawio-mcp-server/build/index.js", "--editor", "--extension-port", "3335"] } } }
- Start opencode TUI → drawio connects (log
mcp connected … tools=28; a node process binds ports 3335 and 3000). - Exit the TUI. The node process keeps running; both ports stay bound.
- Start opencode TUI again, or run
opencode mcp list. opencode spawns a second drawio process, which exits with code 1:
ERROR: Fatal error in main(): Error: [start_websocket_server] Error: Port 3335 is already in use.
→ logmcp connect failed … status.status=failed. - Repeat: every launch adds duplicate processes for every local MCP (observed for drawio, chrome-devtools, ssh-session-mcp, codegraph — three generations alive simultaneously); fixed-port servers fail on each launch.
Screenshot
No response
Operating System
windows11
Terminal
powershell
Activity
opencode-agent commentedon Oct 20, 2026
Thanks for the clear report and steps. I think this is a duplicate of #52965. That issue tracks the same problem: each new client launch (restarting the TUI, running
opencode mcp list, …) starts another copy of every local MCP server under the background service, and the old copies are never stopped. YourEADDRINUSEfailure with drawio-mcp-server happens because the leftover copy is still holding its fixed ports.Possible duplicates and closely related issues, ordered by likelihood:
opencode mcp listruns (Windows, also confirmed on macOS and Linux).It would help to add your 2.0.32 / Windows 11 results to #52965, especially the fixed-port
EADDRINUSEsymptom. It shows a functional break, not just extra memory use.The bot will close this issue as a duplicate in 1 day unless you reply explaining how your problem is different.
kris-cloudaccess commentedon Oct 20, 2026
Same class of bug we measured on Linux (OpenCode 2.0.28–2.0.31): duplicate stdio MCP sets accumulate under the background service. With 3 TUI sessions we saw 5 full sets (~1 GB PSS for the MCP processes alone; the oldest
donsetchhad grown to 401 MB), and onlyservice stop/restartreaps them — session close and app quit do not.Full repro + PSS measurements: #52965. A fix exists in #53046 (lazy MCP start + 60 s idle reclaim of discovery-only connections) — independently validated on Linux and macOS (comments on that PR), still open.
mlimarenko commentedon Oct 20, 2026
#53046 addresses discovery-only connections: lazy startup avoids launching servers just to load a directory, and a fixed 60-second window releases connections opened only for catalog discovery. A tool call or other actual use retains the connection.
Correction to my earlier reply: MCP connections belong to a Location, which can be shared by sessions. Closing one TUI is not sufficient reason to tear them down. I also shouldn't have equated this report with #50363, whose original report concerns orphaned processes reparented to PID 1.
I haven't tested the drawio
EADDRINUSEreproduction against this PR. To establish whether it fixes this case, we'd need the two launches' Location keys and connection IDs, and whether the first connection was discovery-only or retained. The Linux/macOS results linked above show improvement, but don't settle that fixed-port case.opencode-agent commentedon Oct 21, 2026
Closing this as a duplicate of #52965, since there's been no reply saying how it differs. That issue covers the same problem: each new client launch (TUI restart,
opencode mcp list, …) starts another copy of every local MCP server under the background service, and the old copies are never stopped. YourEADDRINUSEfailure with drawio-mcp-server happens because a leftover copy is still holding its fixed ports.It would help to add your 2.0.32 / Windows 11 results to #52965, especially the fixed-port startup failure. If your problem turns out to be different, reply here and we can reopen it.