serve: per-request instances are never disposed - MCP child processes accumulate until memory exhaustion

Description

opencode serve creates a new Instance for every API request that carries a ?directory= parameter, and these instances — along with the MCP server processes they spawn — are never disposed or garbage-collected. Under a client that polls several project directories (e.g. OpenChamber polling session status per directory), child processes accumulate unboundedly until the host exhausts memory.

Observed on a 31GB host: 43 registered project directories × 7 enabled global MCPs → ~900 MCP child processes (~110–200MB each) plus an ~8GB serve heap → 26.9GB RSS → swap thrash → all API requests time out. The log shows "creating instance" every 5–10 seconds continuously (21k+ lines over time), cycling the same directories.

Even after trimming to 2 enabled global MCPs and 26 directories, a freshly started serve accumulates ~185 MCP child processes within minutes — the accumulation itself doesn't stop, it only slows.

Steps to reproduce

1. Start opencode serve --hostname 0.0.0.0 --port <port> (v1.18.29, Linux)
2. Enable a couple of global MCPs in opencode.json (e.g. an npm exec-based one)
3. Poll any endpoint with distinct ?directory= values every few seconds (this mimics OpenChamber's status polling):

   while true; do
     curl -s -H "Authorization: Bearer ..." \
       "http://127.0.0.1:<port>/session/status?directory=/some/repo"
     sleep 5
   done
   

4. Watch the serve process tree: ps --ppid $(pgrep -f 'opencode serve') — the child count and RSS grow without bound; nothing is ever reaped.

Actual vs expected

• Actual: one instance + full MCP fleet spawned per request cycle; processes accumulate forever → memory exhaustion.
• Expected: instances reused per directory (or disposed when idle), and MCP child process trees terminated when an instance is disposed.

OpenCode version

1.18.29 (linuxbrew install)

Operating System

Linux x86_64 (Ubuntu), headless opencode serve behind the OpenChamber web/desktop client.

Additional context

Workarounds we had to apply locally: trimming global MCPs to the bare minimum, a systemd MemoryMax cap, a watchdog that restarts the service when MCP child count > 250 or cgroup memory > 20GB, and a nightly scheduled restart. Happy to share more logs/metrics if useful.