Bug Description

When using the browser tool repeatedly, chrome-devtools-mcp processes accumulate and never get cleaned up. After a few hours of use, dozens of processes remain as orphans, consuming ~6GB of memory.

Steps to Reproduce

1. Use the browser tool multiple times (e.g., browser action=open/snapshot/screenshot)
2. Wait for several hours or trigger several browser operations
3. Run ps aux | grep chrome-devtools-mcp | wc -l — shows 100+ processes

Expected Behavior

Each chrome-devtools-mcp process should terminate when the browser session ends (after client.close() is called).

Actual Behavior

• Process count grows continuously
• client.close() only closes the MCP protocol layer
• The npx wrapper process tree is not terminated properly
• Orphaned watchdog processes remain alive after parent exit

Environment

• OpenClaw version: 2026.5.18
• Node.js: v22.22.2
• OS: Ubuntu 24.04 (Linux 6.8.0-101-generic)
• Chrome: Chromium via ms-playwright

Process Structure Observed

npx -y chrome-devtools-mcp@latest
├── chrome-devtools-mcp (main process)
└── watchdog (child process, --parent-pid=xxx)

When main process is killed, watchdog may survive as orphan.

Memory Impact

• 106 processes observed → ~6 GB RSS memory
• System swap filled: 6.1 GB / 9.9 GB
• Available memory drops from ~400MB to near 0

Root Cause Analysis

The issue appears to be in OpenClaw built-in chrome-mcp-BdBOwUCv.js which uses StdioClientTransport. When client.close() is called, it only closes the MCP protocol layer — the npx wrapper process tree is not properly terminated.

Relevant Code

• File: dist/chrome-mcp-BdBOwUCv.js
• Uses: StdioClientTransport from @modelcontextprotocol/sdk/client/stdio.js
• Session cleanup: line 189 await session.client.close().catch(() => {})

Workaround

pkill -f chrome-devtools-mcp

This temporarily cleans up the orphaned processes and frees ~6GB memory.

Suggested Fix

Either:

1. Make client.close() properly terminate the entire npx process tree, or
2. Use a globally installed chrome-devtools-mcp instead of npx dynamic download each time

Additional Context

This was observed on a memory-constrained VM (3.6GB RAM). The leak is severe enough to cause swap exhaustion and system instability if not manually cleaned.