openclaw - 💡(How to fix) Fix MCP stdio leak fix incomplete for Docker-wrapped MCP servers (parallel spawn case) [1 comments, 2 participants]

Summary

MCP server resource leak from parallel spawn (specialist agents) — fix from #65694 may be incomplete for Docker-wrapped stdio MCP servers.

Environment

• OpenClaw Version: 2026.4.21 (also applies to 2026.4.25)
• Operating System: Ubuntu 22.04 LTS
• MCP Config: Custom MCP servers via plugins.entries + mcp.servers

Bug Description

When multiple specialist agents (SRE, SE, researcher) are spawned in parallel via sessions_spawn, each fires up its own set of MCP servers. When the session ends, the stdio transport's process-tree kill (killProcessTree) terminates the npm/npx wrapper process but does not propagate the signal to Docker containers launched by those wrappers. Result: orphaned Docker containers accumulate.

Observed Behavior (May 1, 2026)

CONTAINER ID   IMAGE                                   COMMAND                  CREATED        STATUS
3629621920fc   ghcr.io/enuno/unifi-mcp-server:latest   "python -m src.main"     18 seconds    (healthy)
8127b0de6d64   ghcr.io/enuno/unifi-mcp-server:latest   "python -m src.main"     37 seconds    (healthy)
f54e5d0aa03d   ghcr.io/enuno/unifi-mcp-server:latest   "python -m src.main"     2 minutes     (healthy)
...

11 unifi-mcp-server Docker containers accumulated in ~10 minutes during a parallel spawn session.

Related Context

• #65694 (closed April 26, 2026) — MCP stdio lifecycle leak; clawsweeper cited fix commit 4a80e61680bb on main
• Fresh comment on #65694 (April 25, 2026) documented 22 accumulated GitHub MCP + 22 Playwright MCP + 11 UniFi containers on OpenClaw 2026.4.21 — same day the bot claimed the fix was implemented
• The bot's closing appears to have been automated/verified against main branch code, not a released version with live deployment evidence

Root Cause Chain

1. sessions_spawn with parallel specialists → each isolated session starts its own MCP server
2. MCP server launched as npm exec @enuno/unifi-mcp-server → Docker wrapper container
3. Session ends → mcp-stdio-transport.ts close() calls killProcessTree(wrapperPid) → npm process dies
4. Docker container's PID 1 inside the container never receives SIGTERM → stays running orphaned
5. Next parallel spawn → new Docker container, old one still present

Evidence

• openclaw/openclaw@src/agents/mcp-stdio-transport.ts:112 — killProcessTree kills the npm wrapper but Docker is a child of that wrapper, not the process being killed
• openclaw/openclaw@src/cron/isolated-agent/run-executor.ts:161 — cleanupBundleMcpOnRunEnd does fire but only kills the outer wrapper
• Each orphaned container: ~50MB RAM + CPU overhead

Expected vs Actual

• Expected: After isolated agent session ends, all MCP server processes (including Docker containers) are terminated
• Actual: npm/npx wrapper dies, Docker container continues running indefinitely

Suggested Fix

1. Immediate: After killProcessTree, enumerate child Docker containers by parsing /proc/<pid>/children or using cgroup info, then docker rm -f <container> for each orphaned child
2. Short-term: Add a Docker-aware process reaper that handles the Docker-in-npm-in-stdio-transport chain
3. Long-term: Use Docker socket or container runtime API to track and clean up MCP containers spawned by the session lifecycle

Impact

• Docker container leak rate: 1 per parallel spawn (e.g., 4 specialists = 4 containers per run)
• Escalates with frequency of parallel specialist sessions
• Eventually exhausts Docker's container namespace or host resources

Workaround

#!/bin/bash
# Kill orphaned unifi-mcp-server containers
docker ps --filter "ancestor=ghcr.io/enuno/unifi-mcp-server:latest" -q | xargs -r docker rm -f
# Run via cron every 5 minutes