Playwright MCP server leaves orphaned browser processes after /mcp reconnect — no cleanup, accumulates over days

Status Open
Maintainer reply None cached
Activity 1 comment · opened Jul 17, 2026

Describe the bug

When the Playwright MCP tool loses its reference to the browser (Error: Target page, context or browser has been closed — happens after ~1h of continuous use in a session), the documented fix is to run /mcp, select playwright, and reconnect. This successfully restores functionality by launching a new browser instance — but the previous browser process is never terminated. It has no crash, receives no signal, and keeps running indefinitely in the background.

Because this happens repeatedly across separate sessions/days without an explicit browser_close, orphaned Chromium instances accumulate silently. Each orphaned instance is a full multi-process browser (main + GPU helper + N renderer helpers + crashpad handlers), so the RAM cost compounds fast.

Impact observed

Over ~3 days (multiple sessions, no machine restart), 26 separate root browser instances accumulated (217 total OS processes), consuming 42.7% of 32GB RAM (~13GB) and contributing to sustained high CPU / machine overheating. This was only discovered because the user noticed the machine running hot and asked for a RAM audit — nothing in the tool surfaced the leak proactively.

Steps to reproduce

  1. Use the Playwright MCP tool (browser_navigate, browser_snapshot, etc.) in a session for an extended period until it fails with Target page, context or browser has been closed.
  2. Run /mcp -> select playwright -> reconnect.
  3. Repeat across several sessions over multiple days without restarting the machine.
  4. Inspect running processes: ps -Ao pid,lstart,command | grep "MacOS/Google Chrome for Testing " | grep -v Helper — multiple root instances will be present, all but the most recent are orphans from prior reconnects.

Expected behavior

On reconnect, the MCP server should either (a) reuse/kill the browser process it previously spawned before launching a new one, or (b) persist the spawned browser's PID/user-data-dir somewhere that survives an MCP server restart, so a new server instance can detect and clean up stale processes from a previous run. A background reaper that kills orphaned ms-playwright processes older than the current session would also solve this.

Environment

  • macOS (Darwin), Claude Code CLI
  • Playwright MCP configured with --isolated (disposable per-session profile, no persistent user-data-dir), --browser chromium (no --executable-path, uses bundled Chromium)

Workaround used

Manually identify the live instance (root Google Chrome for Testing process with the most recent start time) and kill all others plus their child processes: pkill -9 -P <old_pid>; kill -9 <old_pid> for each orphaned root PID.

View original on GitHub ↗

This issue has 1 comment on GitHub. Read the full discussion on GitHub ↗