Repository navigation
Bug: MCP servers spawn duplicate processes per session — 1 project = 8+ instances, 2+ projects = crash #29939
Description
Pre-flight Checks
- I have searched existing issues and this is not a duplicate
- I understand this issue needs status:approved before a PR can be opened
Bug Description
OpenCode spawns independent MCP server processes for each session/project. With 5 MCP servers configured (context7, chrome-devtools, nimgen, grep_app, pencil), a single Desktop session creates 24 node processes consuming 1.8GB RAM. With 2+ projects active, this doubles to 48 processes / 3.6GB, causing system-wide crashes.
Steps to Reproduce
- Configure 5 MCP servers in \opencode.jsonc\
- Open 1 project in OpenCode Desktop → observe 24 MCP node processes
- Open a 2nd project → observe 48 MCP node processes
- System RAM exhausts → ReadableStream controller crash → server goes red/black
Expected Behavior
MCP servers should be shared across sessions (singleton pattern). One context7 process should serve all sessions, not one per session.
Actual Behavior
Each session spawns its own set of MCP servers. No deduplication or scope sharing exists.
Evidence
\\
1 project active:
MCP context7: 8 processes × ~70MB = 552MB
MCP chrome-devtools: 8 processes × ~105MB = 828MB
MCP nimgen: 8 processes × ~60MB = 474MB
Total MCP: 24 processes = 1,888MB (1.8GB)
After cleanup (keeping 2 per type):
6 processes = 314MB — 83% reduction
\\
Operating System
Windows 11
Agent / Client
OpenCode Desktop v1.15.11
Relevant Logs
\\
server.log — every session shows:
MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 exit listeners added to [process]. MaxListeners is 10.
MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 SIGINT listeners added to [process]. MaxListeners is 10.
MaxListenersExceededWarning: Possible EventEmitter memory leak detected. 11 SIGTERM listeners added to [process]. MaxListeners is 10.
\\
Additional Context
- Related to fix(mcp): MCP server loses connection mid-session causing intermittent failures #23997 (MCP connection drops) — the duplication is likely the root cause
- The MaxListenersExceededWarning is a direct consequence: each MCP instance adds exit/SIGINT/SIGTERM listeners
- Workaround: cleanup script that kills duplicate MCP processes, keeping only 2 per type
- Setting \NODE_OPTIONS=--max-listeners=20\ delays but does not fix the issue
Activity
github-actions commentedon May 29, 2026
This issue might be a duplicate of existing issues. Please check:
gabriel-ferraresi commentedon May 29, 2026
Cross-referencing existing issues
The bot flagged #26336, #26714, and #16320 as potential duplicates. Here's how this issue differs:
This issue provides:
If this is consolidated into #26336, the quantitative data and cleanup script from this issue should be preserved.
m13v commentedon May 30, 2026
this is the stdio-binds-to-client-lifecycle pattern, and every multi-session MCP host hits it. stdio servers have no notion of who's connected, so the host's only lever is spawn-a-child-per-session and kill it on session exit. N sessions across M projects = N×M process trees, and that MaxListenersExceededWarning is just each spawn re-registering exit/SIGINT/SIGTERM on the same parent. capping at 2-per-type treats the symptom. the structural fix is a broker owning one long-lived process per server config and multiplexing sessions over it with refcounted shutdown. http+sse sidesteps it entirely because connection and process are already separate.
github-actions commentedon Jul 29, 2026
To stay organized issues are automatically closed after 60 days of no activity. If the issue is still relevant please open a new one.