service: v2 service spawns one local MCP server pair per cataloged project directory at startup

Summary

On startup, the opencode V2 background service (opencode2 serve --service) spawns one full set of local stdio MCP server processes per project directory discovered by its project catalog, instead of one set total. With ~53 directories in the catalog and 2 local MCP servers configured, this produced 51 duplicate MCP process pairs (~153 processes including grandchildren) in a ~70-second burst. The extra processes are never cleaned up and keep running until the service is manually restarted.

Environment

• opencode version: opencode2 v0.0.0-beta-17793 (@opencode-ai/cli, npm)
• OS: macOS 26.x / Darwin Kernel Version 27.0.0, arm64 (Apple Silicon M1)
• Terminal: Ghostty (xterm-256color, truecolor)
• Shell: fish
• Install/channel: beta (npm global)
• Active plugins: none found in config

Reproduction

1. Configure two local stdio MCP servers in ~/.config/opencode/opencode.jsonc (one uv run ... Python server, one native binary):

   {
     "$schema": "https://opencode.ai/config.json",
     "mcp": {
       "servers": {
         "telegram": {
           "type": "local",
           "command": ["uv", "--directory", "/path/to/telegram-mcp", "run", "--locked", "python", "main.py"]
         },
         "cua-driver": {
           "type": "local",
           "command": ["cua-driver", "mcp"]
         }
       }
     }
   }
   

2. Have many directories under $HOME so the project catalog discovers dozens of projects (in this setup the catalog was rooted at /).
3. Start or restart the service (opencode2 service restart, or a fresh boot/login that starts it).
4. Watch the process table:

   ps -eo pid,ppid,lstart,command | grep -E 'telegram-mcp|cua-driver'
   

Expected Behavior

One process tree per configured local MCP server, created lazily and reused across projects/sessions; unused trees terminated when no longer needed.

Actual Behavior

Immediately after service start, one (uv telegram-mcp + cua-driver) pair was spawned roughly every 1–2 seconds for ~70 seconds, then spawning stopped — but all spawned pairs stayed alive indefinitely, all as direct children of the service PID:

51 × uv --directory .../telegram-mcp run --locked python main.py
51 × cua-driver mcp
51 × .venv/bin/python3 main.py   (grandchildren)

Counts verified stable 15+ minutes later; only restarting the service removes them (same leak observed on 2026-08-18 with 43 pairs / 116 connects in 20s on an earlier beta).

Correlation evidence from ~/.local/share/opencode/log/opencode.log: right after service start it emitted 3,061 catalog.updated events covering exactly ~53 unique directories (/, /Users, /Users/kote, /Users/kote/Notes, home subdirectories...), matching the ~51 leaked pairs almost 1:1. No MCP errors are logged during the burst. A remote MCP server configured alongside these (Composio) is unaffected, consistent with only stdio servers being spawned.

Additional Context

• Impact: dozens of idle processes per service start (RAM, plus side effects — each duplicate telegram-mcp opens a Telegram MTProto session, each cua-driver connects to its daemon).
• Recurs on every service start; not tied to opening sessions.
• Workaround: restart the service after login, or keep the number of discoverable project directories small.
• Possibly related open issues: #31554, #29939, #26336, #26714, #30123, #30073, #42270 — those describe per-session/per-restart duplication and orphaned children; this report pins a specific trigger on V2: one spawn set per catalog-discovered directory.