Memory leak in --browserUrl mode under sustained screencast + evaluate_script load: V8 heap grows to ~4GB limit, server aborts (SIGABRT)

[jackzhouusa]

Summary

A long-lived chrome-devtools-mcp server (spawned by an AI coding-agent CLI via npm exec chrome-devtools-mcp@latest) attached to an existing Chrome with --browserUrl steadily grows its JS heap until it hits the default ~4GB V8 heap limit and aborts. The npm exec wrapper process dies alongside it (unhandled-rejection path → uv_kill), so each event leaves a pair of crashed node processes.

This looks distinct from #1192 / #1214: those were --autoConnect-mode collector leaks fixed in March/April — and indeed we saw ~3 months of clean operation after those fixes. The leak reported here reappeared with 1.2.0+ in --browserUrl mode.

Environment

• chrome-devtools-mcp: crashes observed on 1.2.0 and 1.4.0 (resolved fresh via npm exec chrome-devtools-mcp@latest on each start)
• Invocation: npm exec chrome-devtools-mcp@latest -- --browserUrl=http://127.0.0.1:<port> --experimentalScreencast
• node v23.6.0 (Homebrew), macOS 15.7.2 (Apple Silicon)
• Chrome: current stable, attached via CDP (--browserUrl), long-lived instance

Workload profile

The server runs for hours-to-days under an agent that repeatedly: takes snapshots, runs frequent evaluate_script polling, and records repeated screencast_start / screencast_stop cycles against a canvas/WebGL-heavy page.

Observed behavior

Seven crash events over 19 days (2026-06-13 → 2026-07-01), all with the identical signature. Time-to-crash shrinks as automation load increases — process lifetime went 2.7 days → 12.7 h → 3.9 h across the last three events, consistent with a load-proportional leak rather than a fixed-rate one.

Faulting thread (named chrome-devtools-mcp), from the macOS crash report:

libsystem_c.dylib     abort
node                  node::OOMErrorHandler(char const*, v8::OOMDetails const&)
node                  v8::internal::V8::FatalProcessOutOfMemory(...)
node                  v8::internal::Heap::FatalProcessOutOfMemory(char const*)
node                  v8::internal::Heap::CollectGarbage(AllocationSpace, GarbageCollectionReason, ...)
node                  v8::internal::IncrementalMarkingJob::Task::RunInternal()
node                  node::PerIsolatePlatformData::RunForegroundTask(...)
libuv                 uv__async_io → uv__io_poll → uv_run

(Other events show the same FatalProcessOutOfMemory via MinorGCJob / mark-compact — i.e., GC can no longer reclaim; the heap is genuinely retained, not fragmentation.)

Secondary: when the server aborts, the parent npm exec wrapper crashes too, inside PromiseRejectReactionJob → node::Kill/uv_kill — a crash-on-crash in the wrapper's rejection handling that might be worth a defensive fix on its own.

What I've ruled out

• Not system memory pressure: no jetsam kill; the stack is V8's internal heap-limit abort.
• Not the screencast temp-file path: frames are written to disk (fs.mkdtemp → mp4), so suspicion falls on CDP session/protocol-object retention under sustained evaluate_script + screencast churn.
• 1.5.0 changelog contains no related fix, so filing this.

Happy to provide

Full (redacted) .ips crash reports for all seven events, Crashpad minidumps, or a run with --heapsnapshot-near-heap-limit instrumentation if that helps pinpoint the retained objects.

[OrKoN]

Thanks for reporting! What website does it happen with? Does the mcp server operate on a single page app the whole time or are there navigations/reloads involved? Does it require a canvas/WebGL-heavy page or does it happen for other pages for you? Do polling evaluate_script return a lot of data?

[OrKoN]

I think I can reproduce a similar issue with the screencast, I do not need to use evaluate_script, recording a screencast at https://webglsamples.org/aquarium/aquarium.html is enough. I think the issue might be that one WebGL pages the frames are produced much more frequently and if the encoding takes longer the frames are buffered in the server heap. Stopping the screencast seems to release the memory.

[OrKoN]

Which ffmpeg version do you use and which video format do you output?

[jackzhouusa]

Thanks for the fast triage, and good that the aquarium demo already reproduces it. Your buffering hypothesis matches what we see.

Answers to your questions:

1. Page / website: a Godot 3.x game compiled to WebAssembly, rendering to a WebGL canvas continuously (a live game world, not a static page). So yes, it is a canvas/WebGL-heavy page that produces frames at a high, sustained rate, very much like the aquarium sample.

2. SPA vs navigations: effectively a single long-lived page. The game canvas stays mounted for the whole session. There are occasional navigations between test runs, but the heap growth accumulates during one sustained screencast on the game page, not across navigations/reloads.

3. Does it require WebGL: it correlates strongly with screencast activity on that WebGL page. The growth rate tracks how heavy and continuous the screencast workload is; lighter screencast load gives a much longer time to crash. We have not isolated whether a non-WebGL page under equally continuous screencasting would grow as fast, but the WebGL game page is by far our worst case.

4. evaluate_script data volume: we do run periodic evaluate_script to poll game state, but the payloads are small JSON (a handful of fields), not large. Consistent with your repro, screencast alone appears sufficient to see the growth; evaluate_script is not required to trigger it. It may accelerate things but it is not the driver.

5. ffmpeg and output format: ffmpeg 7.1 (Homebrew build on Apple Silicon macOS, with videotoolbox and libx264). Output is mp4 (we do not pass filePath, so it uses the default mkdtemp screencast.mp4).

Two more data points that support "encoding cannot keep up, frames buffer in the server heap":

• The crash signature is always a V8 OOM abort: node::OOMErrorHandler -> v8::FatalProcessOutOfMemory -> abort() at the ~4GB heap ceiling (SIGABRT), not an OS OOM kill.
• Time-to-crash shrinks as screencast load increases (we have seen roughly 2.7 days down to ~4 hours on the same setup). The machine is also under heavy memory pressure (32GB, swap near full), which would slow ffmpeg throughput and widen the gap between frame production and encoding. Stopping the screencast releases the memory for us too.

Happy to run a targeted repro or capture a heap snapshot mid-growth if that would help.

[OrKoN]

Thanks for the details, so it is very likely we see the same issue with screencast. So chrome-devtools-mcp records at 30 fps and currently you would need to ensure that your machine can encode without buffering if you do not have enough memory. This is one of the reasons why the feature is experimental. You could also try to reduce the FPS by modifying the code in your local installation here https://github.com/ChromeDevTools/chrome-devtools-mcp/blob/main/src/tools/screencast.ts#L86 (all options https://pptr.dev/api/puppeteer.screencastoptions). If it helps for your use case, maybe we could add an option to control fps to the MCP server parameters. The other alternative would be to drop frames automatically on Puppeteer side but I am not sure if it is a good idea because that would violate the requested fps. I have a draft puppeteer/puppeteer#15211 which solves the memory usage but degrades the quality of the recording.

Note that I think this is technically not a leak as the memory is released if the recording is stop or if ffmpeg becomes fast. You can also increase the heap size via NODE_OPTIONS=--max-old-space-size=8192 or other ways Node allows you to configure the memory. Please let me know if any of this helped!