browser-mcp.js leaks orphan processes when parent agent exits abnormally — root cause + fix

[sauravvarma]

browser-mcp.js leaks orphan processes when the parent agent exits abnormally — root cause + fix

Filing this as an issue (rather than a PR) because I can't open PRs against this repo. Branch + diff + tests are on my fork: sauravvarma#1

Related: #98, #106.

Why I dug into this

My laptop was thrashing yesterday — 12.7 GB of swap used, load average 13, the fans were loud enough that I went looking for the cause. ps aux | grep browser-mcp found 66 orphan expect-cli/dist/browser-mcp.js processes holding ~2.1 GB of RSS between them. All reparented to launchd (PPID 1), spawned from claude CLI sessions that had long since exited.

Killing them with pkill -9 got the laptop usable again. Same pattern matches #98 (Codex parents) and #106 (stale Chrome on close), so this isn't agent-specific.

Root cause

packages/browser/src/mcp/start.ts only registers handlers for SIGINT, SIGTERM, and beforeExit:

process.once("SIGINT", handleShutdown);
process.once("SIGTERM", handleShutdown);
process.once("beforeExit", () => { void McpRuntime.runPromise(closeSession); });

When the parent agent dies gracefully (sending SIGTERM), the child shuts down. When the parent dies abnormally — crash, force-quit, SIGKILL, or the host being put to sleep mid-session — no signal reaches the child. Its stdin pipe closes, but StdioServerTransport (in the MCP SDK) doesn't propagate stdin EOF as a shutdown. It subscribes to 'data' and 'error' on stdin, not 'end' or 'close'. So the node process keeps running, with Playwright Chromium still attached.

Every abnormal parent exit leaks one browser-mcp.js. They build up across sessions.

Reproduction

Spawn the binary, send an MCP initialize, close stdin to simulate parent death, see if the child exits:

import { spawn } from "node:child_process";
const child = spawn("node", ["apps/cli/dist/browser-mcp.js"], { stdio: ["pipe", "pipe", "inherit"] });
const init = JSON.stringify({
  jsonrpc: "2.0", id: 1, method: "initialize",
  params: { protocolVersion: "2024-11-05", capabilities: {}, clientInfo: { name: "t", version: "0" } },
}) + "\n";
child.stdout.on("data", (c) => { if (c.toString().includes('"id":1')) child.stdin.end(); });
child.stdin.write(init);
child.on("exit", (code) => { console.log("exited", code); process.exit(0); });
setTimeout(() => { console.log("LEAK"); child.kill("SIGKILL"); process.exit(1); }, 8000);

build	result
main @ 0.1.3	hangs past 8s — process would live forever
with fix	exits cleanly in 540 ms, code 0

Fix

Three lines added to start.ts — wire stdin EOF and SIGHUP into the existing handleShutdown path:

process.once("SIGHUP", handleShutdown);
process.stdin.once("end", handleShutdown);
process.stdin.once("close", handleShutdown);

Diff: main...sauravvarma:expect:fix/mcp-stdin-eof-shutdown

Plus two spawn-based regression tests added to apps/cli/tests/mcp-subcommand.test.ts that would have caught the leak — they follow the existing inline pattern in that file, no new helpers introduced.

Notes

• All 215 tests in @expect/browser pass with the fix in place (after pnpm exec playwright install).
• pnpm check / pnpm lint fail on unmodified main in my environment because vp fmt / vp lint can't load vite.config.ts. Pre-existing, didn't touch.
• Same gap likely exists in start-http.ts for the HTTP transport — happy to send a follow-up if useful.
• If you'd rather receive this as a proper PR against main, let me know and how I can work out the permissions issue. The fork branch is ready to merge as-is.

[steven-pribilinskiy]

Corroborating this from Linux, and adding one control that I think strengthens the root cause in the opening post.

Same failure, different platform. Reparented to init rather than launchd, otherwise identical: 126 orphaned expect-cli mcp process trees holding 11.1 GB, spawned by Claude Code sessions that had long since exited. Each leak is a 4-process chain — npm exec → sh -c → expect-cli → browser-mcp.js.

The control, which is why I'm commenting. The obvious competing explanation is the npx wrapper swallowing the signal rather than anything in start.ts. It doesn't hold up. On the same machine, same Claude Code build, same session lifecycles:

MCP server	launched as	orphaned
expect-cli	npx -y expect-cli mcp	126
@upstash/context7-mcp	npx -y @upstash/context7-mcp	0
claude-historian-mcp	npx claude-historian-mcp@beta	0

Byte-identical wrapper form on the first two. So the wrapper is not the variable — which is consistent with the handler set in packages/browser/src/mcp/start.ts being the actual cause, exactly as described above.

What I could reproduce directly: the process does not exit when its stdin closes, which is what happens when the parent agent goes away. SIGINT/SIGTERM/beforeExit don't cover that path.

A detail worth adding for anyone triaging severity: removing the server from the MCP config does not clear the existing ones. 8 hours after I removed it, 24 processes are still alive across 11 sessions, 2.72 GB RSS, the oldest 59 hours old — they're still parented to sessions that happen to be long-running, and they'll reparent to init the moment those end rather than exiting with them. So the leak keeps accruing after uninstall, and ps + kill is the only cleanup.

Happy to test a patch on Linux if the fix in the opening post lands.