Chrome DevTools MCP: live evidence, explicit scope and verifiable browser work
Chrome DevTools MCP architecture: server, daemon session, page routing and profile state
Trace persistent CLI sessions and distinguish selecting a page from isolating its browser state or restricting filesystem access.
What you will learn
- MCP and CLI are two entry paths
- Page routing does not create separate profiles
- Choose launch or attachment by actual need
Before you start
- Basic browser console and network concepts
- Understanding of CLI arguments and local client configuration
Plan a scoped browser investigation and distinguish interface defaults, tool success and end-to-end acceptance.
Key takeaways
- CLI state can persist through a reused daemon.
- Page IDs route requests but do not isolate accounts.
- Launch, attachment and filesystem scope are different choices.
MCP and CLI are two entry paths
An MCP client invokes tools through the server. The experimental CLI acts as a client to a background daemon, using Unix sockets on Linux and macOS and named pipes on Windows. Reusing that daemon preserves browser state across CLI invocations, as described by the CLI guide.
In the inspected entry point, start can stop an existing daemon for the selected session and start it with forwarded arguments. Status reports identity, version and effective arguments. Repeated start is therefore not merely a read-only readiness check and should be separated from observation.
Page routing does not create separate profiles
Page IDs route page-scoped operations to a chosen target. They help prevent accidentally acting on the currently selected tab, but do not give each page independent cookies, storage or account identity. Profile selection and temporary-profile isolation are separate browser lifecycle choices.
The advanced guide still uses an older experimental routing flag name, while the current configuration exposes pageIdRouting enabled by default. This series follows the current configuration and flags that documentation drift instead of prescribing the old example unchanged.
Choose launch or attachment by actual need
By default the MCP server can launch a dedicated Chrome instance. Attachment options connect to an already running debuggable browser; auto-connect also requires browser-side setup and permission. The advanced guide warns that the selected profile can expose all its open windows.
Do not infer a complete authorization boundary from routing or a dedicated daemon name. Browser network policy, profile state and filesystem roots each address different resources. Our isolated tests cover argument serialization only, not daemon isolation, profile cleanup or live attachment behavior.
Decision guide
| Criterion | Option A | Option B |
|---|---|---|
| Best when | You need predictable behavior and easy auditing | You need adaptive optimization and have reliable telemetry |
| Main risk | May leave performance on the table | Can become difficult to explain or debug |
Implementation steps
- 1
Identify whether the client uses MCP or CLI.
- 2
Inspect the active daemon before restarting it.
- 3
Map page routing separately from profile identity.
- 4
Choose attachment only when its state access is intended.
Copy-ready example
{
"architectureWorksheet": true,
"entry": "CLI",
"daemonReused": true,
"targetPageId": null,
"profileIsolated": null,
"pageRoutingIsAccountIsolation": false,
"liveSessionTested": false
}Frequently asked questions
Does every CLI command start a new browser?
The documented daemon is reused, preserving state between commands.
Does a page ID isolate cookies from another page?
No. It routes a target; profile state is a separate concern.
Sources
- Chrome DevTools MCP / docs/cli.mdSource checked 2026-09-14
- Chrome DevTools MCP / docs/advanced-usage.mdSource checked 2026-09-14
- Chrome DevTools MCP / docs/configuration.mdSource checked 2026-09-14
- Chrome DevTools MCP / src/bin/chrome-devtools.tsSource checked 2026-09-14