Summary

Two related memory inefficiencies observed in a stable OpenClaw 2026.5.7 (gitSha b8fe34a) WSL2 deployment where OpenClaw and Hermes are configured to mutually expose each other as tools:

1. Orphan claude mcp serve processes survive session/turn end — reparented to systemd --user, never reaped.
2. Full Hermes MCP child fleet (apify, context7, agentmail, tavily, firecrawl, browser-use) is respawned on every Hermes-as-tool invocation, even when a hermes mcp serve already exists in another scope. The two instances are not duplicates (they belong to different logical scopes) but each pulls in ~1 GB of MCP children that could share a single backing Hermes daemon.

Environment

• OpenClaw 2026.5.7 gitSha b8fe34a
• Ubuntu 24.04 inside WSL2 on Windows
• Hermes 0.10.0 also running locally; both wired to expose each other as MCP tools
• Standard claude-cli shim backend (/root/.hermes/node/bin/claude) via claude-cli/claude-opus-4-7

Observation 1 — orphan claude mcp serve

init(1) ─── systemd --user (329)
              ├── claude mcp serve (PID A)  ← ~192 MB RSS, CWD /root/.openclaw/workspace
              └── claude mcp serve (PID B)  ← ~192 MB RSS, CWD /root/.openclaw/workspace

Both processes started within 3 s of each other and survived their originating session's exit. They were reparented to systemd --user (PID 329) and are not consumed by any current session.

Repro (approximate, timing-sensitive):

1. Start an OpenClaw session that invokes Hermes-as-tool.
2. End the session (close the conversation or kill the orchestrator).
3. pgrep -af 'claude mcp serve' shows orphans, parented to systemd --user.

Cost: ~192 MB × N orphans per missed-cleanup cycle.

Observation 2 — full fleet respawn per invocation

OpenClaw gateway (810 MB persistent)
  ├── OpenClaw session (claude)
  │     └── hermes mcp serve              ← session-scoped Hermes tool exposure
  │           ├── apify/context7/tavily/firecrawl/agentmail/browser-use fleet  (~700 MB)
  │           ├── claude mcp serve        (~191 MB)
  │           ├── codex mcp-server        (~47 MB)
  │           └── openclaw → openclaw-mcp (~270 MB)   ← nests back into OpenClaw
  └── hermes mcp serve                    ← gateway-level Hermes tool exposure
        ├── apify/context7/… fleet        (another ~700 MB)
        └── openclaw → openclaw-mcp       (another ~270 MB)

Each scope that calls Hermes-as-tool spawns a fresh hermes mcp serve plus its full MCP child fleet. The two hermes mcp serve instances are legitimately scoped differently, but each pulls in ~1 GB of MCP children that could share a single backing Hermes daemon.

Suggested fixes

1. Reap children on session end. Track spawned claude mcp serve (and other long-running children) and SIGTERM them when the originating session ends. Add a startup sweep that kills orphans whose CWD matches a known OpenClaw workspace and whose parent is systemd --user.
2. Reuse running Hermes daemon when one already exists locally. When OpenClaw invokes Hermes-as-tool, probe for an already-running hermes mcp serve (or the Hermes gateway socket on its known port) before spawning a new one. Fall back to spawn only if none is running.

Impact

Per active session that crosses agent boundaries: ~700 MB unnecessary MCP-child overhead. Multiplied by orphan cleanup misses, total observed impact was ~3-4 GB on a 7.7 GB WSL2 VM whose legitimate persistent daemon footprint is only ~2 GB.

Cross-reference

Mirror issue (Hermes side, symmetric case where Hermes invokes OpenClaw-as-tool): will link once filed.