Memory leak: chrome-devtools-mcp grows ~13 MB/min in --autoConnect mode, causes OOM

[dzianisv]

chrome-devtools-mcp leaks memory at ~13 MB/min in --autoConnect mode

Environment

• chrome-devtools-mcp@0.19.0 via npm exec
• macOS 15, Chrome 146
• Running as MCP server under opencode serve (long-lived)

Observed behavior

After ~10 hours of idle operation, chrome-devtools-mcp --autoConnect --channel=stable consumed 1,661 MB RSS and contributed to a macOS kernel watchdog panic (swap exhaustion at 8.4 GB total process tree).

Live measurement today after ~9h41m uptime:

PID    RSS      VSZ     ELAPSED COMMAND
3106   303248   418351872  09:41:18 node chrome-devtools-mcp --autoConnect

303 MB RSS after 9.7 hours = growth rate of ~0.5 MB/min in today's session.

In a previous overnight session, the growth rate was steeper (~13 MB/min), reaching 1.66 GB in ~2 hours when Chrome had more active tabs.

Evidence from memory monitor

Our opencode memory monitor captured hourly snapshots. At the time of the crash:

Time	Tree RSS	Children	chrome-devtools-mcp RSS
21:00	3,816 MB	42	652 MB
22:00	5,612 MB	55	1,126 MB
23:00	8,472 MB	55	1,661 MB
07:33	kernel panic (watchdog timeout, LOW swap space)

Expected behavior

An MCP server should have stable memory consumption when idle. A long-running process should not grow unboundedly.

Workaround

We added MCP idle sweep logic in the host (opencode) to periodically close MCP clients that haven't been used within a configurable window. This terminates the leaking process, but it would be better to fix the leak at the source.

Reproduction

1. Start chrome-devtools-mcp --autoConnect --channel=stable as an MCP server
2. Open Chrome with ~10-20 tabs
3. Use the MCP tools occasionally over several hours
4. Monitor RSS with ps -p <PID> -o rss periodically

RSS will grow continuously without bound. The growth rate correlates with the number of active Chrome tabs and DevTools protocol events.

Related

• opencode upstream issue: Multiple memory leaks cause unbounded RAM growth during extended TUI usage anomalyco/opencode#16697
• Full forensics: https://github.com/dzianisv/opencode/blob/dev/docs/memory-forensics.md

[natorion]

which extensions are you using?

[Lightning00Blade]

Hey @dzianisv,
A small fix landed - #1200 and will be release as 0.20.3,
Please try the new version when it's available and tell us if it resolves the issue, or there are still extensive memory usage.

[flobo3]

Hi everyone! PR #1200 has just been merged, which limits the navigations array in PageCollector to prevent HTTPRequest objects from growing indefinitely in --autoConnect mode.

Could you please test the latest main branch and let us know if this resolves the memory leak issue on your end?

[Lightning00Blade]

I was looking at some of the code and we may be keeping some thing from being Garbage collected on the JS heap, which may be the actual underlying issue. CC @nroscino

[perinm]

chiming in to see how I can help I am heavily using codex with multi-repo and multiple worktrees per repo, my memory usage is constantly rising, but split accross multiple different chrome mcp... because I have multiple agents using this, but not much, like a max of 4 sessions at a time, each session with possible subagents using it as well, as far as I understand each runs a different mcp process, is there someway I can more cleanly help you guys? Or is this unrelated? My mcp is crashing all the time, needing me to restart codex to return using chrome mcp

[natorion]

chiming in to see how I can help I am heavily using codex with multi-repo and multiple worktrees per repo, my memory usage is constantly rising, but split accross multiple different chrome mcp... because I have multiple agents using this, but not much, like a max of 4 sessions at a time, each session with possible subagents using it as well, as far as I understand each runs a different mcp process, is there someway I can more cleanly help you guys? Or is this unrelated? My mcp is crashing all the time, needing me to restart codex to return using chrome mcp

Which version of the MCP are you using? Does it include the fix mentioned above? Are all the instances you are using utilizing --autoConnect?

[perinm]

chiming in to see how I can help I am heavily using codex with multi-repo and multiple worktrees per repo, my memory usage is constantly rising, but split accross multiple different chrome mcp... because I have multiple agents using this, but not much, like a max of 4 sessions at a time, each session with possible subagents using it as well, as far as I understand each runs a different mcp process, is there someway I can more cleanly help you guys? Or is this unrelated? My mcp is crashing all the time, needing me to restart codex to return using chrome mcp

Which version of the MCP are you using? Does it include the fix mentioned above? Are all the instances you are using utilizing --autoConnect?

I am using --autoConnect, yes, I even tried disabling analytics, but still my mcp breaks, like now it just did again, see attached images.

My codex mcp config are:

[mcp_servers.chrome-devtools]
command = "npx"
args = ["-y", "chrome-devtools-mcp@latest", "--autoConnect", "--usageStatistics", "false"]

[mcp_servers.chrome-devtools-codex]
command = "npx"
args = ["-y", "chrome-devtools-mcp@latest", "--autoConnect", "--usageStatistics", "false", "--channel", "beta"]

[mcp_servers.chrome-devtools-background]
command = "npx"
args = ["-y", "chrome-devtools-mcp@latest", "--headless", "--isolated", "--usageStatistics", "false", "--channel", "beta"]

Though I usually just use the beta autoConnect one

Full message, from more codex debugging, in case it might help:

Yes. The break is understood now.

**What actually happened**

It was not “no MCP server.” It was the opposite: too many.

Right now your machine has:
- `22` `chrome-devtools-mcp` beta `--autoConnect` processes
- `20` stable `--autoConnect` processes
- `22` headless beta `--isolated` processes

So Codex is leaking helper processes across restarts instead of keeping one clean lane.

Relevant config is correct in [config.toml](/Users/hariseldon/.codex/config.toml):
- personal stable lane
- Codex beta lane
- headless beta lane

Chrome Beta itself is alive:
- process `12647` is running
- [DevToolsActivePort](/Users/hariseldon/Library/Application%20Support/Google/Chrome%20Beta/DevToolsActivePort) exists
- it points at port `63197`
- that port is listening from the Beta process

So the failure was not “Beta dead.”  
The likely failure was:
1. Codex spawned yet another beta auto-connect helper.
2. That specific helper tried to attach during a bad window.
3. It concluded `DevToolsActivePort` was unavailable.
4. Meanwhile old helper processes stayed alive, creating control-plane clutter.

**Important nuance**

The beta lane is fragile during attach, but the bigger issue is hygiene:
- one broken helper should die and be replaced cleanly
- instead, they accumulate

That guarantees weirdness over time.

**What this means**

Weak explanation:
- “Chrome broke”

Correct explanation:
- the browser was mostly fine
- the selected Codex helper attached at the wrong moment
- Codex kept stale MCP helpers around
- repeated restarts turned one lane into a pile of competing orphan processes

**Dominant move**

Do not keep debugging this ad hoc forever.

The strong move is:
1. add a root control-plane rule/backlog item for MCP helper cleanup and attach-race recovery
2. define one explicit recovery command for when Chrome lanes get weird
3. later, if this repeats, wire a cleaner startup policy instead of tolerating process pileup

**Exact one-time recovery command**

If you want to clean the mess manually when this happens:

``bash
pkill -f 'chrome-devtools-mcp'
pkill -f 'playwright-mcp'
``

Then restart Codex and, if needed, Chrome Beta.

I did not run that because you asked to understand the break, not to kill active helpers.

**Bottom line**

The break was not a mystery.  
It was a leaked-process control-plane problem plus an attach-race on the specific beta MCP lane.

Then I tried using again without restarting neither killing anything neither executing any command, and it worked.
I wonder if I should use this mcp server as a proxy or something, so I inly run one or 2 instances of the real thing, and connects multiple agents to such proxy.

[achiya-automation]

I ran into the same memory leak issue on my M2 MacBook — Chrome MCP processes accumulating RAM until the system became unusable.

I ended up building an alternative that uses native Safari via AppleScript instead of Chrome DevTools Protocol. No extra browser process, no memory accumulation — it reuses your existing Safari with a persistent ~5ms-per-command Swift daemon.

If anyone here is on macOS and wants to try a lighter approach: https://github.com/achiya-automation/safari-mcp (80 tools, MIT licensed, works with Claude Code/Cursor/Windsurf).

Obviously not a fix for this issue, but it might help as a workaround for macOS users dealing with Chrome's resource overhead.

[sarthakagrawal927]

Adding another data point — this caused two kernel panics within 12 minutes on my M1 Pro MacBook Pro (16GB, macOS 26.3.1).

Context

I was using the MCP in --autoConnect mode with a website cloning tool (ai-website-cloner-template) that automates Chrome DevTools for reverse-engineering websites — taking screenshots at multiple breakpoints, extracting computed styles/design tokens, and downloading assets. This is a much more intensive usage pattern than idle browsing.

What happened

Chrome ballooned to ~10GB RAM during the automated inspection loops. The system hit 95%+ memory utilization, which starved the kernel's VM compressor and swap subsystem.

Panic #1: After 6 days uptime, during a DarkWake maintenance cycle. Watchdog timeout on CORE 0 — 90 seconds with no checkin. 10 swapfiles, 23% compressed pages.

Panic #2: 11 minutes after the reboot from Panic #1. Fresh boot, zero sleep/wake cycles, only 58 watchdog checkins. Same CORE 0 watchdog timeout through AppleInterruptControllerV2. The system barely had time to start up — Spotlight re-indexing + the still-resident Chrome memory pressure from the previous session was enough to trigger it again.

Key detail

The automated screenshot/inspection workflow creates DOM snapshots and screenshot buffers that are never released by the MCP. This is a much faster leak path than the idle --autoConnect growth reported in the original issue — we're talking minutes to OOM, not hours.

Workaround

Disabled Chrome MCP entirely. Switched to Raycast for search (disabled Spotlight with sudo mdutil -a -i off since Spotlight re-indexing on boot after a panic compounds the problem).

Environment

• macOS 26.3.1 (25D2128)
• M1 Pro (MacBookPro18,1), 16GB RAM
• Darwin Kernel 25.3.0 (xnu-12377.91.3~2/RELEASE_ARM64_T6000)
• Chrome DevTools MCP via --autoConnect