How to Let a Coding Agent Control Your Existing Chrome Browser With Chrome DevTools MCP

To let a coding agent inspect a page already open in Chrome, use Chrome DevTools MCP to connect it to Chrome’s debugging tools. MCP (Model Context Protocol) is a standard that lets an agent find and call tools provided by another program. Chrome DevTools MCP provides browser tools, and Chrome gives those tools access to pages and browser data.

For an existing Chrome profile, use auto-connect. First enable remote debugging in Chrome, then configure the MCP server. Finally, approve the connection in Chrome. This route requires Chrome 144 or later. A manual debugging-port connection serves a different purpose: it connects to a separate Chrome instance with its own profile.

Either route gives the agent meaningful control. Review what the connection exposes before approving it, especially if the browser contains personal or sensitive sessions.

What the connection gives the agent

The coding agent is the MCP client, the program that requests and calls tools. Chrome DevTools MCP is the MCP server, the program that provides those tools. It exposes tools for actions such as navigating pages, along with tools for taking screenshots and debugging. It also provides tools for analyzing performance. The server uses Chrome’s debugging capabilities to work with the browser. The project says its browser automation uses Puppeteer in its README.

Connecting to an active profile lets the agent work with the browser state you have already established, such as a page where you reproduced a bug or signed in. That access extends beyond the visible page. Chrome warns that the agent can access open tabs, cookies, session and local storage, and other data exposed through JavaScript. The connection can also reach open windows for the selected profile. If multiple profiles are active, the documented auto-connect behavior uses Chrome’s default profile. See Chrome’s auto-connect guidance for details.

Chrome asks you to approve an auto-connect session. That prompt gives you a chance to reject an unexpected request, but approval grants the connected agent access to browser data. Connect only an agent you trust, and avoid using a sensitive profile when a separate test profile would do.

Connect to your existing profile with auto-connect

Use auto-connect when you want the agent to work with the Chrome session already open on your machine. Chrome’s configuration instructions require Chrome 144 or later.

First, open this address in Chrome and enable remote debugging:

chrome://inspect/#remote-debugging

Then add Chrome DevTools MCP to the MCP configuration used by your coding agent. The following example uses npx to run the package and opts out of the two documented telemetry categories:

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp@latest",
        "--autoConnect",
        "--no-usage-statistics",
        "--no-performance-crux"
      ]
    }
  }
}

The configuration file’s location and the steps for reloading it depend on the coding agent. After saving the configuration, restart or reload the MCP server as that client requires.

Ask the agent to do a low-risk test, such as listing open pages or navigating a test tab. When Chrome displays the permission prompt, approve it only if you expected the request. After connecting, give the agent a specific task and check its actions in the browser.

The two flags disable separate kinds of data collection. --no-usage-statistics disables Chrome DevTools MCP usage-statistics collection. --no-performance-crux prevents URLs from performance traces from being sent to the Chrome User Experience Report service. These flags do not establish how the coding-agent provider handles or retains information it receives. Check that provider’s privacy and data-handling terms separately.

Use a separate browser with a debugging port

A manual connection works when the MCP server runs in a sandbox, an isolated environment that cannot launch Chrome, or when you want a separate browser profile. It does not connect the agent to your ordinary Chrome profile.

Chrome 136 and later ignore remote-debugging port and pipe switches when Chrome uses its default data directory. Chrome requires a non-default --user-data-dir for this method. The requirement is intended to help protect browser data from cookie theft. The remote-debugging change explains the restriction.

Close existing Chrome instances before launching a separate debug-enabled instance. For example, on macOS:

/Applications/Google\ Chrome.app/Contents/MacOS/Google\ Chrome \
  --remote-debugging-port=9222 \
  --user-data-dir=/tmp/chrome-profile-stable

On Linux, use the Chrome executable installed on your machine with the same flags:

/usr/bin/google-chrome \
  --remote-debugging-port=9222 \
  --user-data-dir=/tmp/chrome-profile-stable

On Windows, launch Chrome with --remote-debugging-port=9222 and a --user-data-dir pointing to a dedicated directory. The executable path and shell syntax depend on your installation and command prompt.

The custom data directory keeps this browser’s data separate from the default profile. Sign in to sites in this dedicated profile if the agent needs an authenticated test session; Chrome does not carry over the normal profile’s signed-in state.

Configure the MCP server to use the port you selected. Port 9222 is a common example, not a requirement:

{
  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "-y",
        "chrome-devtools-mcp@latest",
        "--browser-url=http://127.0.0.1:9222",
        "--no-usage-statistics",
        "--no-performance-crux"
      ]
    }
  }
}

The --browser-url value must use the same port as the Chrome command. Keep the debug-enabled browser open while the agent connects, then close it when you finish. The MCP project warns that any application on the machine can connect to an exposed debugging port and control that browser. Its advanced connection notes describe this risk and the separate-profile setup.

Choose the connection that matches your goal

Auto-connect is the direct choice when you want the agent to use a live Chrome profile and Chrome 144 or later is available. It requires enabling remote debugging and approving the connection, and it gives the agent access to data associated with the selected profile.

Use a manual port when the MCP server cannot launch Chrome or when you want a deliberately separate profile. That route requires a custom data directory and exposes a control port to local applications while the browser runs. It is useful for isolated testing, but it does not provide the existing default profile’s session.

Resolve common connection problems

If auto-connect times out, check that Chrome is version 144 or later, remote debugging is enabled, and you approved the connection prompt. The MCP troubleshooting guide also recommends checking whether another tool is connecting to the same debugging port. A sandboxed client may lack permission to launch Chrome. One documented alternative is to start Chrome outside the sandbox and connect with --browser-url. Follow the manual-port precautions above.

If you use a virtual machine or WSL, connection behavior can differ from a direct host setup. The project documents specific host-validation and environment-related issues in its troubleshooting guide. Follow the instructions for your environment instead of assuming that a working local connection will work unchanged across a VM boundary.

What I'm building

Delegate tasks. Get software.

Give Vroni a GitHub issue, bug report, spec, or rough idea. It reads the repo, plans the change, writes code, runs checks, and works toward a review-ready pull request.

Take a look at vroni.com