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

[ArsenicBismuth]

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:

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

[PrashantBhanage]

I'd like to work on this,
could someone assign it to me?

[PrashantBhanage]

my first theory (missing default channel) was wrong — channel already defaults to 'stable' via the yargs middleware regardless of --auto-connect, and I confirmed --auto-connect alone works cleanly on Linux (permission prompt appears, list_pages returns real data).

Digging further: with no explicit --user-data-dir, this connects via puppeteer.connect({channel: 'chrome'}), which resolves the default profile path via @puppeteer/browsers's resolveDefaultUserDataDir. On Windows that's process.env['LOCALAPPDATA'] || path.join(os.homedir(), 'AppData', 'Local') + Google\Chrome\User Data.

@ArsenicBismuth — could you check two things on your machine:

Does explicitly passing --user-data-dir "%LOCALAPPDATA%\Google\Chrome\User Data" (alongside --auto-connect) fix it?
Can you confirm whether LOCALAPPDATA is actually present in the environment OpenCode spawns the MCP server with (e.g. temporarily add console.error(process.env.LOCALAPPDATA) early in chrome-devtools-mcp.ts, or check via OpenCode's own env/debug settings)?

If LOCALAPPDATA is missing/wrong in that spawned environment, this is likely an OpenCode process-spawning issue rather than a chrome-devtools-mcp bug — but chrome-devtools-mcp could still improve this by validating the resolved user data dir exists and giving a clearer error instead of a generic connection failure.

[nattallius]

Hi, can you try manually substitute port( from DevToolsActivePort file or chrome://inspect/#remote-debugging ) and provide it as --browser-url param. So configuration looks like this:

  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "chrome-devtools-mcp@latest",
        "--browser-url=http://127.0.0.1:<port_number>"
      ]
    }
  }
}

And let usknow if it connects this way.
Also in the meantime you can take a look at guide https://github.com/ChromeDevTools/chrome-devtools-mcp#connecting-to-a-running-chrome-instance

[ArsenicBismuth]

@nattallius Browser-url doesn't work:

"command": ["npx", "-y", "chrome-devtools-mcp@latest", "--browser-url=http://127.0.0.1:9222"],

@PrashantBhanage User data dir doesn't work:

"command": ["npx", "-y", "chrome-devtools-mcp@latest", "--auto-connect", "--user-data-dir '%LOCALAPPDATA%/Google/Chrome/User Data'"],

[ArsenicBismuth]

I added console.error on the chrome-devtools.js, but I don't see it anywhere in the opencode log.

[ArsenicBismuth]

UPDATE! Good news, @PrashantBhanage's suggestion actually works! But I have to give it explicit path:

"command": ["npx", "-y", "chrome-devtools-mcp@latest", "--auto-connect", "--user-data-dir", "C:/Users/USER/AppData/Local/Google/Chrome/User Data"],

Using env var doesn't work, even if the expanded path (as shown in the red error text) is correct.

So I guess the root cause is env var not expanding? That would cause even the default (without --user-data-dir) to fail? But this is strange because the error message clearly shows the expanded path:

Could not connect to Chrome. Check if Chrome is running.
Cause: Could not find DevToolsActivePort for chrome at C:\Users\USER\AppData\Local\Google\Chrome\User Data\DevToolsActivePort

[ArsenicBismuth]

DeepSeek generates this response in regard to my situation, and why the other command parameters fail:

If the last paragraph is true, then @nattallius's --browser-url solution would work, but not for my usecase as I think from the readme using --remote-debugging-port=9222 would require me using --user-data-dir, thus not using the usual profile as I wanted.

[ArsenicBismuth]

I think revising this README is also good, it took me several read that this section only refers to the flag, but the chrome://inspect method is not affected by it as they have two distinct implementation.

For security reasons, Chrome requires you to use a non-default user data directory when enabling the remote debugging port [via --remote-debugging-port flag]. You [must] 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.

*Square brackets are my corrections.

cc. @OrKoN

[PrashantBhanage]

I think revising this README is also good, it took me several read that this section only refers to the flag, but the chrome://inspect method is not affected by it as they have two distinct implementation.

For security reasons, Chrome requires you to use a non-default user data directory when enabling the remote debugging port [via --remote-debugging-port flag]. You [must] 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.

*Square brackets are my corrections.

cc. @OrKoN

@ArsenicBismuth catching something in your two --user-data-dir attempts — I think they weren't actually testing the same thing.

Your failing attempt:

packs the flag name and value into one array element. Since command is an array (no shell involved), each element becomes exactly one argv token , nothing re-splits on spaces. So yargs never sees a --user-data-dir flag with a separate value; it sees one unmatched token, and userDataDir stays unset entirely. That means this attempt silently fell back to the same default-resolution path as plain --auto-connect with nothing , it wasn't really testing env var expansion, it was accidentally re-testing "no user-data-dir" again.

Your working attempt correctly splits it as two array elements that's the only one that actually passed a value through.

So I think the env-var-expansion angle is a red herring, and the real bug narrows down to resolveDefaultUserDataDir (in @puppeteer/browsers) not computing the right path automatically on Windows when spawned via OpenCode even though an explicit correct path works fine.

Since console.error didn't show up in the OpenCode log, that's inconclusive rather than a "LOCALAPPDATA is missing" confirmation OpenCode may just not surface subprocess stderr at all. Could you try writing straight to a file instead, so we bypass OpenCode's logging entirely?

require('fs').writeFileSync('C:/temp/mcp-env-debug.txt', JSON.stringify(process.env, null, 2));

Drop that early in chrome-devtools-mcp.ts (or chrome-devtools-mcp-main.ts), run OpenCode normally, then check C:/temp/mcp-env-debug.txt for whether LOCALAPPDATA/USERPROFILE actually reach the subprocess. That'll tell us definitively whether this is an OpenCode env-passthrough issue or a genuine bug in the default-path resolution logic.

Also +1 on your README point about --remote-debugging-port vs chrome://inspect being distinct code paths that's worth its own doc fix regardless of how this one shakes out.

[PrashantBhanage]

Hi, can you try manually substitute port( from DevToolsActivePort file or chrome://inspect/#remote-debugging ) and provide it as --browser-url param. So configuration looks like this:

  "mcpServers": {
    "chrome-devtools": {
      "command": "npx",
      "args": [
        "chrome-devtools-mcp@latest",
        "--browser-url=http://127.0.0.1:<port_number>"
      ]
    }
  }
}

And let usknow if it connects this way. Also in the meantime you can take a look at guide https://github.com/ChromeDevTools/chrome-devtools-mcp#connecting-to-a-running-chrome-instance

@nattallius thanks for looking at this ,worth noting ArsenicBismuth already tried --browser-url above and it didn't connect either.

Quick summary of where we've landed so far: an explicitly-passed literal --user-data-dir path works fine, but the automatic default-path resolution (what runs when you use plain --auto-connect with no explicit dir) doesn't find the running Chrome on Windows via OpenCode. That resolution goes through @puppeteer/browsers's resolveDefaultUserDataDir, which reads process.env['LOCALAPPDATA'] and falls back to os.homedir() + AppData\Local if it's missing.

We ruled out one candidate cause already an env-var-expansion attempt turned out to be a JSON-array formatting mistake (flag+value crammed into one array element), not a real test of env var passthrough.

@ArsenicBismuth is running a diagnostic now (writing process.env to a file directly, bypassing OpenCode's log capture) to confirm whether LOCALAPPDATA/USERPROFILE actually reach the subprocess when OpenCode spawns it. Once that comes back we should know whether this is a chrome-devtools-mcp/@puppeteer/browsers bug or an OpenCode process-spawning issue ,happy to send a PR once we know which.