{"slug": "chrome-devtools-mcp-1-7-debug-memory-leaks-without-reading-raw-heap-snapshots", "title": "Chrome DevTools MCP 1.7: debug memory leaks without reading raw heap snapshots", "summary": "Chrome DevTools MCP 1.7 introduces new tools for debugging memory leaks, including get_heapsnapshot_object_details and native-context summaries, enabling AI coding agents to analyze heap snapshots without reading raw files. The update also improves cleanup of heap-snapshot workers and provides a three-snapshot protocol for reliable leak detection.", "body_md": "Chrome DevTools MCP 1.7 gives AI coding agents a stronger memory-debugging path: a new object-details tool, native-context summaries and filters, an updated first-party memory-leak skill, and fixes that dispose heap-snapshot workers more reliably.\n\nDo not hand a multi-gigabyte `.heapsnapshot`\n\nfile to an LLM or ask it to guess from one snapshot. Use a three-snapshot protocol:\n\n``` php\nbaseline -> repeat one suspected action 10 times -> target\n         -> reverse/close the action -> final\n```\n\nStart with summaries, compare retained growth, isolate one suspicious class or native context, inspect representative objects and retaining paths, then close every loaded snapshot. A fix passes only when the same replay no longer exceeds a predeclared growth budget.\n\nThis guide is for developers using Codex, Claude Code, Cursor, Copilot, Gemini CLI, or another MCP-capable agent to diagnose browser or Node.js memory growth. It assumes you can reproduce one bounded action such as opening and closing a modal, navigating between views, reconnecting a stream, or processing one job.\n\nIf you first need the browser access and safety model, use the [general Chrome DevTools MCP workflow](https://dev.to/blogs/chrome-devtools-mcp-ai-agent-debugging-workflow/). This page goes deeper on heap evidence and cleanup; it is not another console/network debugging overview.\n\nThe August 10 release adds `get_heapsnapshot_object_details`\n\n, which lets an agent request known metadata for a specific heap node instead of reading a raw snapshot. Snapshot summaries now expose native contexts and their sizes, while `get_heapsnapshot_details`\n\ncan filter objects by native context.\n\nThe bundled memory-leak skill now routes analysis through native MCP tools: summaries, snapshot comparison, class nodes, retaining paths, dominators, object details, duplicate strings, and category filters. It explicitly recommends capturing baseline, target, and final snapshots, repeating the suspected action ten times, and closing loaded snapshots afterward.\n\nVersion 1.7 also fixes two diagnostic-server cleanup paths: workers are disposed when a context tears down and when loading a missing or invalid snapshot fails. Those fixes reduce the chance that the debugger's own worker growth is confused with application growth, but they do not remove your responsibility to close snapshots or verify the active CLI and daemon versions.\n\n| Stage | Question | Smallest useful tool output | Stop condition |\n|---|---|---|---|\n| Summary | Did retained memory grow? |\n`get_heapsnapshot_summary` for three snapshots |\nNo repeatable growth after cleanup |\n| Comparison | Which classes accumulated? |\n`compare_heapsnapshots` summary, then one class diff |\nGrowth is noise or expected cache |\n| Context | Which page/frame/context owns it? | native-context sizes and filtered details | Wrong context or cross-page contamination |\n| Object | What is one representative instance? | class nodes plus `get_heapsnapshot_object_details`\n|\nObject is expected and bounded |\n| Retainer | Why is it still reachable? | retaining path, retainers, dominators, edges | Chain does not reach application code |\n| Fix proof | Did the same replay improve? | fresh three-snapshot run and budget result | Budget still fails |\n\nDo not jump directly to a source-code change because a class name looks suspicious. Detached DOM nodes can be intentional caches; large strings can be generated output; framework objects may only be the visible end of a longer retaining chain.\n\nRecord the Chrome DevTools MCP version, agent client, browser or Node target, URL/process, commit, and exact reproduction. For this workflow, require 1.7.x on both sides when a daemon is used. The release adds a CLI warning for CLI/daemon version mismatch; treat that warning as a failed preflight.\n\nUse a disposable profile or test account. Heap snapshots can contain application strings and object data, so keep snapshot paths out of source control and external prompts.\n\nChoose an action with a reverse operation:\n\n``` php\nopen modal -> close modal\nmount route -> navigate away\nsubscribe -> unsubscribe\nstart job -> finish and release job\n```\n\nDeclare the loop count and pass rule before looking at the result. Example: ten open/close cycles must leave no more than two extra modal roots, no growing listener set, and less than 5 MB of retained growth after cleanup. The numbers are workload-specific; the important part is fixing them before diagnosis.\n\nStabilize the app, then capture `baseline`\n\n. Repeat the action ten times and capture `target`\n\n. Perform the reverse action, leave the app idle long enough for normal cleanup, and capture `final`\n\n.\n\nKeep the same build, profile, page, input, and loop count. A reload between snapshots changes the experiment and makes the comparison hard to defend.\n\nRun `get_heapsnapshot_summary`\n\non all three snapshots. Compare total size, object counts, dominant classes, and native contexts. Then use `compare_heapsnapshots`\n\nfor baseline-to-target and baseline-to-final.\n\nTarget growth alone does not prove a leak. The stronger signal is growth that remains in `final`\n\nafter the reverse action. If a separate native context owns most of the increase, filter to it before asking for individual objects.\n\nFor a suspicious class, list instances with `get_heapsnapshot_class_nodes`\n\n. Pick a representative node from the final snapshot and request `get_heapsnapshot_object_details`\n\n. Then inspect retainers, retaining paths, dominators, and edges until the chain reaches application-owned state.\n\nUse category filters to test specific hypotheses: objects retained by detached DOM nodes, event handlers, execution contexts, or console references. Use duplicate-string analysis only when string growth dominates the comparison.\n\nFix the first application-owned edge that should have been released: remove a listener, clear a timer, unsubscribe, bound a cache, delete a map entry, release an observer, or break a stale closure. Do not delete framework state merely because it dominates the heap.\n\nPair the change with a durable regression check where practical. The [agent-instruction guide](https://dev.to/blogs/agents-md-vs-claude-md-copilot-instructions/) shows how to require evidence before edits, while the [package-vetting workflow](https://dev.to/blogs/vet-npm-package-before-installing-ai-built-app/) helps when the retaining path enters a new dependency.\n\nRestart from a clean process or page state and run the identical three-snapshot protocol. Compare the same metrics and class/context. Close every loaded snapshot with `close_heapsnapshot`\n\n, including snapshots from failed hypotheses.\n\nReport `pass`\n\nonly when the replay meets the predeclared budget. Otherwise report the remaining growth and next retaining-chain hypothesis.\n\n`.heapsnapshot`\n\nfile into the model and exhausting context.The [WebMCP security checklist](https://dev.to/blogs/webmcp-agent-ready-website-security-checklist/) is useful when the inspected page exposes agent-callable actions; memory diagnosis does not relax write or data-access boundaries.\n\n```\ndate / owner / commit:\nagent_client:\nchrome_devtools_mcp_cli / daemon_version:\ntarget_url_or_process:\nsnapshot_storage / retention:\nsuspected_action / reverse_action:\nloop_count: 10\npass_budget:\nbaseline_summary:\ntarget_summary:\nfinal_summary:\nlargest_native_context_delta:\nsuspicious_class / representative_node_id:\nretaining_path_to_application_code:\nfix / regression_check:\nreplay_result: pass | fail\nsnapshots_closed: yes | no\nremaining_risk / next hypothesis:\n```\n\nIt should not. The first-party skill says raw heap snapshots are extremely large and recommends native MCP summary, comparison, class, object, and retaining-path tools instead.\n\nNo. The action may intentionally allocate memory. Stronger evidence is retained growth that survives the reverse action in the final snapshot and points through a retaining chain to application-owned state.\n\nA browser process can contain multiple pages, frames, extensions, or execution contexts. Version 1.7 can summarize their sizes and filter details by context, helping the agent avoid blaming the wrong page.\n\nNo. It fixes specific worker-disposal paths. You still need matched versions, valid paths, bounded experiments, and explicit `close_heapsnapshot`\n\ncleanup.", "url": "https://wpnews.pro/news/chrome-devtools-mcp-1-7-debug-memory-leaks-without-reading-raw-heap-snapshots", "canonical_source": "https://dev.to/ahab_indieseek/chrome-devtools-mcp-17-debug-memory-leaks-without-reading-raw-heap-snapshots-3j0b", "published_at": "2026-08-12 10:21:05+00:00", "updated_at": "2026-08-12 10:47:36.590970+00:00", "lang": "en", "topics": ["developer-tools", "ai-agents", "artificial-intelligence"], "entities": ["Chrome DevTools MCP", "Codex", "Claude Code", "Cursor", "Copilot", "Gemini CLI"], "alternates": {"html": "https://wpnews.pro/news/chrome-devtools-mcp-1-7-debug-memory-leaks-without-reading-raw-heap-snapshots", "markdown": "https://wpnews.pro/news/chrome-devtools-mcp-1-7-debug-memory-leaks-without-reading-raw-heap-snapshots.md", "text": "https://wpnews.pro/news/chrome-devtools-mcp-1-7-debug-memory-leaks-without-reading-raw-heap-snapshots.txt", "jsonld": "https://wpnews.pro/news/chrome-devtools-mcp-1-7-debug-memory-leaks-without-reading-raw-heap-snapshots.jsonld"}}