chrome-devtools-mcp subprocess leak: not reaped on gateway shutdown or session end

Summary

When the Hermes gateway spawns chrome-devtools-mcp (e.g. through an hermes mcp add chrome-devtools-... server entry, used during a browser-related agent run), the subprocess survives session end and gateway restart. On a host running Hermes 0.13.0 (2026.5.7) alongside an OpenClaw gateway, an unmanaged chrome-devtools-mcp had been alive 23 h 20 m under the live Hermes gateway from a session that ended hours earlier — the gateway never reaped it.

Repro

1. Add chrome-devtools-mcp as an MCP server in Hermes (the documented hermes mcp add flow, e.g. as in website/docs/guides/use-mcp-with-hermes.md).
2. Run any agent prompt that triggers a chrome-devtools-mcp tool call. The gateway spawns npm exec chrome-devtools-mcp@latest --autoConnect.
3. End the session (close the agent, finish the cron, etc.) without an explicit MCP-shutdown step.
4. Observe: the npm exec chrome-devtools-mcp wrapper + its chrome-devtools-mcp child + the telemetry watchdog node child all stay alive, parented to the live Hermes gateway PID.
5. Restart the gateway (or let it die for any reason): the npm-exec wrapper's PPID drops to 1 (launchd on macOS / init on Linux). Successive sessions accumulate orphans indefinitely.

Evidence

macOS 25.4.0, Hermes 0.13.0 (commit 2026.5.7), chrome-devtools-mcp 1.0.1.

$ pgrep -af 'chrome-devtools-mcp' | head -5
48591   npm exec chrome-devtools-mcp@latest --browserUrl=http://127.0.0.1:9222    age 23:20:34  PPID=93565
48602   chrome-devtools-mcp                                                       age 23:20:33  PPID=48591
93565   /Library/Frameworks/Python.framework/.../Python -m hermes_cli.main gateway run --replace   age 3-08:14:54

PID 48591/48602 are leftovers from a Hermes-driven chrome-devtools session that ended 23+ hours before this snapshot. The Hermes gateway (PID 93565, 3 days uptime) is still alive but does not reap them.

Combined with similar OpenClaw-side leaks on the same host, total swap pressure on a 32 GB Mac reached 15.77 GB used / 17.4 GB total (1.6 GB free) — extreme enough to trigger jetsam kills of unrelated foreground processes. Explicit kill -TERM of the 12 non-legitimate chrome-devtools-mcp PIDs (orphan + 23h-stale) freed ~10 GB of swap immediately.

Docs reviewed

• website/docs/user-guide/features/browser.md line 31 mentions "automatic cleanup — inactive sessions are closed after a timeout" — that refers to Browserbase/browser-use sessions, not the chrome-devtools-mcp subprocess.
• website/docs/guides/use-mcp-with-hermes.md documents hermes mcp add chrome-devtools-... --command cmd.exe --args /c "npx -y chrome-devtools-mcp@latest --autoConnect --no-usage-statistics" (WSL path) and a similar Unix pattern. No documented teardown for the spawned subprocess on session/gateway shutdown.
• RELEASE_v0.4.0.md and the gateway source under hermes_cli/ do not appear to track spawned MCP child PIDs for explicit termination.

Suggested fix

Track spawned MCP child PIDs in the gateway (or whatever layer spawns them via the command/args config), then:

1. On gateway shutdown signal (SIGTERM, SIGINT, lid-close, hermes gateway stop): send SIGTERM to each tracked PID with a short escalation to SIGKILL.
2. On session-end (subagent/cron/ACP/one-shot completion): if no other live session is using a given MCP server instance, terminate it.

This would mirror best practice for stdio-MCP host processes elsewhere in the ecosystem and prevent a slow-burn memory leak across multi-day uptimes.

Workaround

A local LaunchAgent that runs every 15 min, walks chrome-devtools-mcp ancestry, and kills wrappers whose npm exec parent is PID 1, OR whose parent is the Hermes gateway AND age > 60 min. Happy to share if useful.

Cross-platform context

The same chrome-devtools-mcp lifecycle gap affects the OpenClaw gateway on the same host. Filed at openclaw/openclaw#84413 (where I commented with macOS-specific evidence). The two bugs are independent but share a root cause: any host process that spawns chrome-devtools-mcp and does not explicitly track + kill the children will leak the subprocess on restart.