Repository navigation
MCP child-process leak: server never reaps MCP children per (re)connection, leading to unbounded memory growth #52410
Description
The MCP child-process leak. The server spawns a full set of model-connector child processes per client connection and never reaps the dead ones; reconnect a web tab a few times and the set multiplies. The cost has been paid once in full: memory grew by about 20 GB in about 65 minutes and killed the service, with every active session on it. The leak stays visible even on health, to the tune of 55 live children, 40 of them connector workers, on a one-day-old instance at snapshot. What we do instead: 48 GB of RAM as headroom, a deliberately lean connector set, closed web tabs, and a drafted upstream report. Headroom is containment, not a fix.
Metadata
Metadata
Assignees
Labels
No labels
Activity
github-actions commentedon Oct 1, 2026
This issue doesn’t fully meet our contributing guidelines.
What needs to be fixed:
Please edit this issue to address the above within 2 hours, or it will be automatically closed.
This issue might be a duplicate of existing issues. Please check:
If you believe this was flagged incorrectly, please let a maintainer know.
ExNihil14 commentedon Oct 1, 2026
Windows data point for the same leak (stdio, not only web clients).
Setup: Windows 11, OpenCode v2.0.17 at the time of measurement (updated to 2.0.21 afterwards), 6 MCP servers
(4 local stdio), 3 workspaces/directories, no web tabs involved.
Observed: the server re-establishes MCP connections for every workspace roughly once per hour
(
mcp connected server=…entries inopencode.log). On Windows the old stdio process trees are neverreaped — see #52251, where the
pgrep -Pdescendant walk is skipped on this platform — and stdioservers are started eagerly regardless of use. Net effect: each (re)connection can leave a live
process tree behind.
Worst case — a local server with a wrapper chain. Our stdio server is a uv-tool shim:
serena.exe->python.exe->python.exe. One instance started at 09:37 UTC, completed itsinitialization (language server ready, workspace scan done, its log written), then the log went
silent and the whole tree stayed alive for 6+ hours while the connection for the same workspace was
recreated three times (10:29, 11:30, 12:32 UTC). Right after a reconnect we measured 4 process
trees for 3 workspaces (~12 processes); per-instance logs under
~/.serena/logs/<date>/mcp_<ts>_<pid>.txtconfirm one instance per connection.
Interim mitigation (bounds the leak, not a fix): a small watchdog that kills a tree when its
instance log has not been updated for >60 min while a newer tree exists (exit code 1 when
trees > workspaces). Happy to provide more data (process-tree dumps, log tails) if useful.
github-actions commentedon Oct 4, 2026
This issue has been automatically closed because it was not updated to meet our contributing guidelines within the 72-hour window.
Feel free to open a new issue that follows our issue templates.