Most MCP clients start one Chrome DevTools MCP server per conversation. If your
client shares a single server instance across concurrent agents or subagents,
start the server with --experimentalPageIdRouting. This exposes pageId on
page-scoped tools so each agent can route tool calls to the tab it is working
with.
{
"mcpServers": {
"chrome-devtools": {
"command": "npx",
"args": [
"-y",
"chrome-devtools-mcp@latest",
"--experimentalPageIdRouting"
]
}
}
}If you run multiple independent MCP client sessions and want each session to
launch its own temporary Chrome profile, also pass --isolated. This avoids
sharing the default Chrome DevTools MCP user data directory between those
server instances.
By default, chrome-devtools-mcp starts a Chrome's stable channel instance using the following user
data directory:
- Linux / macOS:
$HOME/.cache/chrome-devtools-mcp/chrome-profile - Windows:
%USERPROFILE%\.cache\chrome-devtools-mcp\chrome-profile
For non-stable channels, the channel name is appended to the directory name, for example
chrome-profile-canary.
The user data directory is not cleared between runs and is reused for subsequent
runs with the same channel. Only one browser can use it at a time. Set the isolated
option to true to use a temporary user data directory instead which will be cleared
automatically after the browser is closed.
By default, the Chrome DevTools MCP server will start a new Chrome instance with a dedicated profile. This might not be ideal in all situations:
- If you would like to maintain the same application state when alternating between manual site testing and agent-driven testing.
- When the MCP needs to sign into a website. Some accounts may prevent sign-in when the browser is controlled via WebDriver (the default launch mechanism for the Chrome DevTools MCP server).
- If you're running your LLM inside a sandboxed environment, but you would like to connect to a Chrome instance that runs outside the sandbox.
In these cases, start Chrome first and let the Chrome DevTools MCP server connect to it. There are two ways to do so:
- Automatic connection (available in Chrome 144): best for sharing state between manual and agent-driven testing.
- Manual connection via remote debugging port: best when running inside a sandboxed environment.
Step 1: Set up remote debugging in Chrome
In Chrome (>= M144), do the following to set up remote debugging:
- Navigate to
chrome://inspect/#remote-debuggingto enable remote debugging. - Follow the dialog UI to allow or disallow incoming debugging connections.
Step 2: Configure Chrome DevTools MCP server to automatically connect to a running Chrome Instance
To connect the chrome-devtools-mcp server to the running Chrome instance, use
--autoConnect command line argument for the MCP server.
The following code snippet is an example configuration for gemini-cli:
{
"mcpServers": {
"chrome-devtools": {
"command": "npx",
"args": ["chrome-devtools-mcp@latest", "--autoConnect"]
}
}
}Step 3: Test your setup
Make sure your browser is running. Open gemini-cli and run the following prompt:
Check the performance of https://developers.chrome.com
Note
The autoConnect option requires the user to start Chrome. If the user has multiple active profiles, the MCP server will connect to the default profile (as determined by Chrome). The MCP server has access to all open windows for the selected profile.
The Chrome DevTools MCP server will try to connect to your running Chrome instance. It shows a dialog asking for user permission.
Clicking Allow results in the Chrome DevTools MCP server opening developers.chrome.com and taking a performance trace.
You can connect to a running Chrome instance by using the --browser-url option. This is useful if you are running the MCP server in a sandboxed environment that does not allow starting a new Chrome instance.
Here is a step-by-step guide on how to connect to a running Chrome instance:
Step 1: Configure the MCP client
Add the --browser-url option to your MCP client configuration. The value of this option should be the URL of the running Chrome instance. http://127.0.0.1:9222 is a common default.
{
"mcpServers": {
"chrome-devtools": {
"command": "npx",
"args": [
"chrome-devtools-mcp@latest",
"--browser-url=http://127.0.0.1:9222"
]
}
}
}Step 2: Start the Chrome browser
Warning
Enabling the remote debugging port opens up a debugging port on the running browser instance. Any application on your machine can connect to this port and control the browser. Make sure that you are not browsing any sensitive websites while the debugging port is open.
Start the Chrome browser with the remote debugging port enabled. Make sure to close any running Chrome instances before starting a new one with the debugging port enabled. The port number you choose must be the same as the one you specified in the --browser-url option in your MCP client configuration.
For security reasons, Chrome requires you to use a non-default user data directory when enabling the remote debugging port. You can specify a custom directory using the --user-data-dir flag. This ensures that your regular browsing profile and data are not exposed to the debugging session.
macOS
/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome --remote-debugging-port=9222 --user-data-dir=/tmp/chrome-profile-stableLinux
/usr/bin/google-chrome --remote-debugging-port=9222 --user-data-dir=/tmp/chrome-profile-stableWindows
"C:\Program Files\Google\Chrome\Application\chrome.exe" --remote-debugging-port=9222 --user-data-dir="%TEMP%\chrome-profile-stable"Step 3: Test your setup
After configuring the MCP client and starting the Chrome browser, you can test your setup by running a simple prompt in your MCP client:
Check the performance of https://developers.chrome.com
Your MCP client should connect to the running Chrome instance and receive a performance report.
If you hit VM-to-host port forwarding issues, see the “Remote debugging between virtual machine (VM) and host fails” section in troubleshooting.md.
For more details on remote debugging, see the Chrome DevTools documentation.
Please consult these instructions.