What is the difference between --isolated and my normal Chrome profile?

--isolated launches Chrome against a brand-new, throwaway profile with no history, cookies, saved logins, or extensions from your everyday browser, and that profile is discarded when the server stops. Without it, chrome-devtools-mcp uses (or creates) a persistent profile directory, which is what you want if you need to stay logged in to sites across sessions. Setting --isolated together with --user-data-dir is a conflict: isolated mode always wins and the path is ignored.

Do I need --headless for chrome-devtools-mcp to work in CI?

Yes, in almost every CI runner. --headless=false is the default, which tries to open a visible Chrome window; CI containers typically have no display server, so the launch fails or falls back to a virtual framebuffer you have to configure yourself. Pairing --headless with --isolated is the common CI combination: no window, no leftover profile between runs.

How do I connect chrome-devtools-mcp to a Chrome I already have open?

Start Chrome yourself with a remote-debugging port, for example chrome --remote-debugging-port=9222, then set --browser-url=http://127.0.0.1:9222 (attach mode in the generator above). This skips launching a second Chrome entirely and reuses whatever tabs, cookies, and extensions are already loaded in that window. --channel, --headless, --isolated, and --executable-path are all ignored once --browser-url is set, since no new browser process is being started.

Why does my --channel flag get ignored?

Two situations silently drop --channel. First, if you also set --executable-path, the explicit binary path wins because both flags answer the same question (which Chrome to launch) and the more specific one takes priority. Second, --channel only applies in launch mode. In attach mode (--browser-url) or WebSocket mode (--ws-endpoint) there is no new binary being started, so the flag has nothing to act on.

What does --slim mode disable?

--slim trims the tool categories chrome-devtools-mcp registers with the MCP client, keeping only the core set instead of loading every performance, network, and debugging tool up front. It reduces how much context the tool list consumes on every turn. It does not disable any CLI connection flags: --headless, --isolated, and --browser-url all still work normally with --slim set.

Can I point chrome-devtools-mcp at a remote Chrome over CDP?

Yes, with --ws-endpoint set to a ws:// or wss:// Chrome DevTools Protocol URL, which is the WebSocket mode in the generator above. This is the option for a Chrome running in a separate container, a cloud browser service, or any host you cannot reach with a plain HTTP debugging port. Pass --ws-headers as a JSON string if the endpoint needs an Authorization header.

Do I need --accept-insecure-certs for local HTTPS testing?

Only if the site you are testing serves a self-signed or otherwise untrusted certificate, which is common for local dev servers on https://localhost. Without the flag, Chrome blocks the page load with a certificate warning and chrome-devtools-mcp tools that depend on the page loading (snapshot, screenshot, network capture) will fail or time out.

How do I stop chrome-devtools-mcp from touching my regular Chrome profile?

Set --isolated. Without it, launch mode either reuses your default profile directory or the one you passed via --user-data-dir, both of which persist bookmarks, extensions, and login sessions across runs. That is fine for daily-driver debugging but risky if an agent is clicking around unattended. --isolated guarantees a clean, disposable profile every time the server starts.

Back to Tools

Chrome DevTools MCP Setup: Which Connection Mode Do You Need?

Chrome DevTools MCP setup gets confusing fast once you add flags: launch a fresh Chrome, attach to one you already have open, or point at a raw CDP endpoint. Pick a mode below, and the generator flags every flag combination that silently gets ignored before you copy anything.

Updated July 17, 2026 · By Jim Liu(verified against the chrome-devtools-mcp CLI reference)

Example output: headless CI setup

npx -y chrome-devtools-mcp@latest \
  --headless --isolated --slim

Three flags, zero conflicts. The generator would show this panel empty.

TL;DR

Pick a connection mode first. Launch a new Chrome, attach to one you already started with --remote-debugging-port, or connect over a raw CDP WebSocket. The mode you pick decides which other flags do anything.
Watch the conflict panel. --isolated silently overrides --user-data-dir, --executable-path silently overrides --channel, and attach/WebSocket modes ignore every launch-only flag. The generator names each one instead of letting it fail quietly.
Copy the command or the full config. Either the raw npx command line, or a complete mcpServers JSON entry ready to paste into ~/.claude.json.
Verify. Restart Claude Code and run claude mcp list to confirm chrome-devtools connected.

Pick how Chrome DevTools MCP reaches Chrome

Every field updates the command instantly. No submit, no signup.

Connection mode

Server name in mcpServers

ChannelViewport

Executable path (optional)Overrides --channel when both are set.User data directory (optional)

--headless--isolated

Tool categories▾

Performance (on by default)Network (on by default)Emulation (on by default)Extensions (off by default)

Advanced▾

--slim (trims unused tool categories from context)--accept-insecure-certsProxy serverLog file path

Merge into existing config (optional)▾

npx -y chrome-devtools-mcp@latest

Next: apply this config

1Copy the Command or Full Config tab above.
2Open ~/.claude.json (or .mcp.json for project scope) and paste it in.
3Restart Claude Code, then run `claude mcp list`.
4Type /mcp in a session to confirm chrome-devtools connected.

Real setups people actually use

4 scenarios

Click a card to load its flags into the form above. Edit before copying.

Flag conflicts the generator catches

None of these fail loudly on their own. chrome-devtools-mcp just uses whichever flag takes precedence and ignores the other, so the config still starts, it just does not do what you asked. The generator surfaces each case instead of letting it pass silently.

--isolated + --user-data-dir

Why: Both decide which profile Chrome loads. --isolated always creates a fresh throwaway one.

Result: --user-data-dir is ignored whenever --isolated is set. Drop one or the other.

--channel + --executable-path

Why: Both select which Chrome binary to launch. The explicit path is more specific.

Result: --executable-path wins; --channel is ignored if both are present.

--browser-url + launch-only flags

Why: Attach mode connects to a Chrome that is already running, so nothing new gets launched.

Result: --channel, --headless, --isolated, --executable-path, --user-data-dir, and --viewport are all ignored in attach mode.

--ws-endpoint + launch-only flags

Why: Same root cause as attach mode: a raw CDP endpoint bypasses Chrome-launch logic entirely.

Result: --channel, --headless, and --isolated have nothing to act on and are ignored.

Chrome DevTools MCP flags, grouped by category

chrome-devtools-mcp exposes more CLI options than most people ever set by hand. These are the ones this generator produces, grouped by what they control and which connection mode they apply to.

Connection

Which of these apply depends on the connection mode you pick above. The generator hides the ones that would be ignored.

Flag	Type	Best for
--channel	canary · dev · beta · stable	launch
--executable-path	string	launch
--browser-url	string (http://...)	attach
--ws-endpoint	string (ws:// or wss://)	websocket
--ws-headers	JSON string	websocket

Profile & window

Launch-mode only. Attach and WebSocket modes reuse whatever profile and window the remote Chrome already has.

Flag	Type	Best for
--isolated	boolean, default false	launch
--user-data-dir	string	launch
--headless	boolean, default false	launch
--viewport	WIDTHxHEIGHT	launch

Tool categories

Valid in every connection mode: these turn whole groups of MCP tools on or off.

Flag	Type	Best for
--category-performance	boolean, default true	all modes
--category-network	boolean, default true	all modes
--category-emulation	boolean, default true	all modes
--category-extensions	boolean, default false	all modes

Network & misc

Also valid in every connection mode.

Flag	Type	Best for
--proxy-server	string	all modes
--accept-insecure-certs	boolean, default false	all modes
--slim	boolean, default false	all modes
--log-file	string	all modes

Frequently asked questions

What is the difference between --isolated and my normal Chrome profile?: --isolated launches Chrome against a brand-new, throwaway profile with no history, cookies, saved logins, or extensions from your everyday browser, and that profile is discarded when the server stops. Without it, chrome-devtools-mcp uses (or creates) a persistent profile directory, which is what you want if you need to stay logged in to sites across sessions. Setting --isolated together with --user-data-dir is a conflict: isolated mode always wins and the path is ignored.
Do I need --headless for chrome-devtools-mcp to work in CI?: Yes, in almost every CI runner. --headless=false is the default, which tries to open a visible Chrome window; CI containers typically have no display server, so the launch fails or falls back to a virtual framebuffer you have to configure yourself. Pairing --headless with --isolated is the common CI combination: no window, no leftover profile between runs.
How do I connect chrome-devtools-mcp to a Chrome I already have open?: Start Chrome yourself with a remote-debugging port, for example chrome --remote-debugging-port=9222, then set --browser-url=http://127.0.0.1:9222 (attach mode in the generator above). This skips launching a second Chrome entirely and reuses whatever tabs, cookies, and extensions are already loaded in that window. --channel, --headless, --isolated, and --executable-path are all ignored once --browser-url is set, since no new browser process is being started.
Why does my --channel flag get ignored?: Two situations silently drop --channel. First, if you also set --executable-path, the explicit binary path wins because both flags answer the same question (which Chrome to launch) and the more specific one takes priority. Second, --channel only applies in launch mode. In attach mode (--browser-url) or WebSocket mode (--ws-endpoint) there is no new binary being started, so the flag has nothing to act on.
What does --slim mode disable?: --slim trims the tool categories chrome-devtools-mcp registers with the MCP client, keeping only the core set instead of loading every performance, network, and debugging tool up front. It reduces how much context the tool list consumes on every turn. It does not disable any CLI connection flags: --headless, --isolated, and --browser-url all still work normally with --slim set.
Can I point chrome-devtools-mcp at a remote Chrome over CDP?: Yes, with --ws-endpoint set to a ws:// or wss:// Chrome DevTools Protocol URL, which is the WebSocket mode in the generator above. This is the option for a Chrome running in a separate container, a cloud browser service, or any host you cannot reach with a plain HTTP debugging port. Pass --ws-headers as a JSON string if the endpoint needs an Authorization header.
Do I need --accept-insecure-certs for local HTTPS testing?: Only if the site you are testing serves a self-signed or otherwise untrusted certificate, which is common for local dev servers on https://localhost. Without the flag, Chrome blocks the page load with a certificate warning and chrome-devtools-mcp tools that depend on the page loading (snapshot, screenshot, network capture) will fail or time out.
How do I stop chrome-devtools-mcp from touching my regular Chrome profile?: Set --isolated. Without it, launch mode either reuses your default profile directory or the one you passed via --user-data-dir, both of which persist bookmarks, extensions, and login sessions across runs. That is fine for daily-driver debugging but risky if an agent is clicking around unattended. --isolated guarantees a clean, disposable profile every time the server starts.

More MCP setup guides on OpenAI Tools Hub

Claude Code MCP config generator: stdio, HTTP, and SSE servers MCP server boilerplate generator: scaffold a starter server MCP vs A2A protocol: when to use each Claude Code MCP CLI integration guide