ChromeDevTools / ChromeDevTools/chrome-devtools-mcp

`auto-connect` never works, despite manual websocket script works just fine

Open
#2,458 19 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

collecting-feedback
Dominant language
TypeScript
Stars
52.3k
Forks
4.3k
Avg merge
2d 7h
Merged PRs (30d)
83

Description

UPDATE:

Workaround for my issue: Need to supply --user-data-dir, and must be explicit path, no env var. Example:
"command": ["npx", "-y", "chrome-devtools-mcp@latest", "--auto-connect", "--no-usage-statistics", "--user-data-dir", "C:/Users/USER/AppData/Local/Google/Chrome/User Data"]

Description of the bug

No matter how much I try, the MCP just never discovers the existing Chrome (v150) with remote debugging enabled. My code to test it manually works just fine (at the bottom). But MCP gives the output below:

Image

And I do see the DevToolsActivePort file at that directory.

Also I tested without auto-connect configuration and it works, the MCP would open a chrome and control/read it normally. But my use-case requires attaching to an opened chrome.

Script to get all titles from opened tabs

Save as get_title.mjs then run with:
node get_title.mjs

Once run, my Chrome would see a prompt to allow connection, and then read the title in the tabs on approval.

import fs from 'node:fs';
import path from 'node:path';

const CHROME_UDD =
  process.env.CHROME_USER_DATA_DIR ||
  path.join(process.env.LOCALAPPDATA, 'Google', 'Chrome', 'User Data');

function readDevToolsEndpoint() {
  const portPath = path.join(CHROME_UDD, 'DevToolsActivePort');
  const content = fs.readFileSync(portPath, 'utf8');
  const lines = content.split('\n').map((l) => l.trim()).filter(Boolean);
  const port = parseInt(lines[0], 10);
  if (Number.isNaN(port) || port <= 0 || port > 65535) throw new Error(`Invalid port '${lines[0]}'`);
  return `ws://127.0.0.1:${port}${lines[1]}`;
}

const ws = new WebSocket(readDevToolsEndpoint());
await new Promise((resolve, reject) => {
  ws.onopen = resolve;
  ws.onerror = reject;
});

const pending = new Map();
let nextId = 1;

ws.onmessage = (ev) => {
  const msg = JSON.parse(ev.data);
  if (msg.id && pending.has(msg.id)) {
    const { resolve, reject } = pending.get(msg.id);
    pending.delete(msg.id);
    msg.error ? reject(new Error(msg.error.message)) : resolve(msg.result);
  }
};

function send(method, params = {}) {
  const id = nextId++;
  ws.send(JSON.stringify({ id, method, params }));
  return new Promise((resolve, reject) => pending.set(id, { resolve, reject }));
}

const { targetInfos } = await send('Target.getTargets');
for (const t of targetInfos.filter((t) => t.type === 'page')) {
  console.log(t.title || '(untitled)');
}

ws.close();
Reproduction
  1. Open Chrome.
  2. Enable remote debugging in: chrome://inspect/#remote-debugging
  3. Open Agentic CLI (in this case OpenCode).
  4. See MCP are active, and it can access its tools.
  5. Prompt: "Check the performance of https://developers.chrome.com"
Expectation

There's a prompt in my existing Chrome to initialize the connection, and MCP allows agent to get information regarding it.

MCP configuration
{
  "$schema": "https://opencode.ai/config.json",
  "mcp": {
    "chrome-devtools": {
      "type": "local",
      "command": ["npx", "-y", "chrome-devtools-mcp@latest", "--auto-connect", "--no-usage-statistics"],
      "enabled": true
    }
  }
}
Chrome DevTools MCP version

1.6.0

Chrome version

150

Coding agent version

OpenCode v1.18.11

Model version

DeepSeek-V4-Flash-0731

Chat log

No response

Node version

22.12.0

Operating system

Windows

Extra checklist
  • I want to provide a PR to fix this bug

Contributor guide

Open the contributing guide

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start at the MCP command path that handles --auto-connect and --user-data-dir, then reproduce on Windows with Chrome's DevToolsActivePort and the supplied configuration. Done means an existing Chrome is discovered with an explicit user-data-dir, while the existing manual and non-auto-connect behavior remains intact.

Written by the indexing model from the issue text.

Assessment

Tech stack
node.js, typescript
Domain
devtools, tooling
Issue type
Bug
Difficulty
3/5
Estimated time
1-2 days
Activity status
Active
Clarity
Mostly clear
Newbie friendliness
52/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.