Awareness: OpenClaw gateway MCP process pool never cleans up uvx processes, causing memory leak

Context

This is not an issue with the MiniMax-Coding-Plan-MCP itself, but wanted to make you aware of how it behaves when used with OpenClaw.'s MCP integration.\n\n## Issue\n\nWhen called via OpenClaw's MCP integration, each tool invocation spawns a new uvx minimax-coding-plan-mcp process pair (uv tool + python). OpenClaw never terminates these processes, leading to:\n\n- 88 processes after several days of normal usage\n- ~6GB RAM consumed\n- Only resolvable by restarting the OpenClaw gateway\n\n## Environment\n\n- MCP Server: minimax-coding-plan-mcp\n- Client: OpenClaw 2026.4.2 (d74a122)\n- OS: Linux Ubuntu\n\n## Question\n\nIs this the expected behavior? Is there a recommended way to limit the number of concurrent uvx instances from the MCP server side?\n\n## Related\n\nA bug report has been filed with OpenClaw: https://github.com/openclaw/openclaw/issues/62026\n\nThe issue appears to be in OpenClaw's gateway process pool lifecycle management, not in the MCP server itself. Just wanted to cross-post here in case others hit the same problem and search this repo first.

No repository file or test is identified; start by reviewing the related OpenClaw issue #62026 and the reported process behavior with OpenClaw 2026.4.2 on Ubuntu. Done would require a confirmed server-side mitigation or a clear determination that lifecycle cleanup belongs in OpenClaw.