Summary

On OpenClaw 2026.4.2, MCP stdio servers appear to accumulate across turns and are not cleaned up properly.

Observed servers:

• @modelcontextprotocol/server-sequential-thinking
• @upstash/context7-mcp
• mcp-deepwiki / mcp-instruct

This caused repeated memory growth on a 15 GiB VPS until restart.

Environment

• OpenClaw version: 2026.4.2
• Host OS: Linux x64
• Session type: Telegram direct chat
• Agents affected: not limited to one agent; global mcp.servers exposure made this reproducible across agents

What I observed

1. Multiple batches of the same MCP-related processes were spawned under openclaw-gateway over time.
2. They were created repeatedly across conversation turns, even when logs did not show explicit calls to all corresponding tools on each turn.
3. The processes did not get cleaned up after the turn finished.
4. Memory usage kept increasing until service restart.

At peak I observed roughly:

• about 180 MCP-related processes
• about 13.5 GiB RSS combined

Representative process families:

• npm exec @modelcontextprotocol/server-sequential-thinking
• node /root/.npm/_npx/.../mcp-server-sequential-thinking
• npm exec @upstash/context7-mcp --api-key ...
• node /root/.npm/_npx/.../context7-mcp --api-key ...
• npm exec mcp-deepwiki
• node /root/.npm/_npx/.../mcp-instruct

Important behavior

I removed these MCP servers from config by changing:

"mcp": {
  "servers": {}
}

However, after config apply / hot reload, old leaked MCP child processes were still present.

So there seem to be two related issues:

1. MCP server lifecycle leak / accumulation during normal turns
2. Config reload does not clean up already spawned MCP child processes that are no longer configured

Evidence

Before mitigation

Representative counts from live inspection:

• count=180 total_rss=13471.2 MiB

Later, after restart and more turns, more batches reappeared.

After removing MCP config

Config correctly became:

"mcp": {
  "servers": {}
}

But old processes were still alive, for example:

• server-sequential-thinking
• context7-mcp
• mcp-deepwiki
• mcp-instruct

and process count was still non-zero because old instances were not reaped by reload.

Why this looks like an OpenClaw runtime issue

This does not look like a single third-party MCP server bug, because multiple different MCP servers accumulated in the same pattern under openclaw-gateway.

It looks more like OpenClaw's MCP process lifecycle management is:

• spawning new stdio servers repeatedly
• not reusing or reaping them correctly
• and not fully cleaning removed servers on config reload

Expected behavior

• MCP stdio servers should either be reused safely or terminated after use
• completed turns should not leave stale MCP child processes behind indefinitely
• removing mcp.servers from config should stop and reap previously managed MCP child processes

Actual behavior

• MCP child processes accumulate over time
• memory usage keeps growing
• hot reload/config apply does not fully clean old MCP child processes
• only stronger restart/cleanup restores memory

Suggested investigation areas

• MCP stdio server lifecycle ownership under openclaw-gateway
• per-turn tool/mcp bootstrap path spawning behavior
• child process cleanup on turn completion
• child process cleanup on config reload / server removal
• whether MCP tool listing/bootstrap is causing eager respawn each turn

If helpful, I can also provide a more detailed timestamped process timeline from live inspection.