autoConnect does not work for Chrome 144

[ProjectBetelgeuse]

Description of the bug

I have try to use the opencode and connect it to the MCP. I set it to autoConnect. Updated to Chrome 144 and enabled the Remote debugging. But it always timeout and I don't see any change in the chrome. It output chrome-devtools_new_page [url=https://developers.chrome.com]. But it didn't open any new page and timed out.

Also in the doc there is a inconsistance out the autoConnect version support. At some place it said 145+ but for the tutorial of how to autoConnect it said 144+.

Reproduction

1. Use "opencode"
2. Add MCP to to it. "chrome-devtools": { "type": "local", "command": ["npx", "-y","chrome-devtools-mcp@latest", "--autoConnect", "--channel=beta"], } or "chrome-devtools": { "type": "local", "command": ["npx", "-y","chrome-devtools-mcp@latest", "--autoConnect", "--channel=stable"], } or "chrome-devtools": { "type": "local", "command": ["npx", "-y","chrome-devtools-mcp@latest", "--autoConnect"], }
3. Use chrome 144 and toggle the remote debugging.
4. Tell AI in the opencode to check the performance of https://developers.chrome.com

Expectation

For chrome 144+. The autoConnect should work by follow the doc in the readme.

MCP configuration

"chrome-devtools": {
  "type": "local",
  "command": ["npx", "-y","chrome-devtools-mcp@latest", "--autoConnect", "--channel=stable"],
}

Chrome DevTools MCP version

v0.13.0

Chrome version

144.0.7559.60

Coding agent version

opencode 1.1.21

Model version

Claude opus 4.5

Chat log

No response

Node version

24.11.0

Operating system

macOS

Extra checklist

• [ ] I want to provide a PR to fix this bug

[OrKoN]

@natorion @matthiasrohmer could you please help reproduce this?

[OrKoN]

@ProjectBetelgeuse can you confirm that opencode actually installs the latest chrome-devtools-mcp@latest version and that you started the server in chrome://inspect/#remote-debugging

[ProjectBetelgeuse]

@ProjectBetelgeuse can you confirm that opencode actually installs the latest chrome-devtools-mcp@latest version and that you started the server in chrome://inspect/#remote-debugging

@OrKoN Yes, I use the mcp using the command like this: "command": ["npx", "-y","chrome-devtools-mcp@latest", "--autoConnect", "--channel=stable"]. So I think it is the lastest. And also I did enable the "Allow remote debugging for this browser instance". When it first start. I ask me if I allow the automated test. I click allow. But then it stuck and give this error McpError: MCP error -32001: Request timed out I am not sure why. I am using the opencode in warp and in vscode terminal. Both didn't work. In the mean time the agent want to use mcp. I am getting notification from the script editor that said "opencode agent is ready for input". Not sure if this is related.

[OrKoN]

If you have seen the accept dialog, it means that the auto-connect works and timeout happens with whatever is the logic of the tool call after the connection:

• what tool call does the client send when it times out?
• what timeout does the client have for MCP calls? is it the standard 60 secs?
• do you have any extensions in the stable instance? do you have a lot of tabs open (can you try with one open tab?)?
• could you capture the debug logs as described in https://github.com/ChromeDevTools/chrome-devtools-mcp/blob/main/docs/troubleshooting.md?

It is also easier to test with MPC inspector:

• Run npx @modelcontextprotocol/inspector npx chrome-devtools-mcp@latest --auto-connect
• When UI opens click Connect and then List tools and then pick the list_pages tool and send the command.

This should return a list of pages in your stable Chrome instance (after a confirmation dialog). This is how I tested with and I am not able to reproduce.

[zzh948498]

If you have seen the accept dialog, it means that the auto-connect works and timeout happens with whatever is the logic of the tool call after the connection:

• what tool call does the client send when it times out?
• what timeout does the client have for MCP calls? is it the standard 60 secs?
• do you have any extensions in the stable instance? do you have a lot of tabs open (can you try with one open tab?)?
• could you capture the debug logs as described in https://github.com/ChromeDevTools/chrome-devtools-mcp/blob/main/docs/troubleshooting.md?

It is also easier to test with MPC inspector:

• Run npx @modelcontextprotocol/inspector npx chrome-devtools-mcp@latest --auto-connect
• When UI opens click Connect and then List tools and then pick the list_pages tool and send the command.

This should return a list of pages in your stable Chrome instance (after a confirmation dialog). This is how I tested with and I am not able to reproduce.

The same problem

[kriomant]

Any call leads to timeout. And I can't see request in "Protocol monitor" devtools pane.

[yotahk]

Same here, call to any tool fails with connection timeout. My Chrome is Version 144.0.7559.60 (Official Build) (arm64).

Also in the doc there is a inconsistance out the autoConnect version support. At some place it said 145+ but for the tutorial of how to autoConnect it said 144+.

The help message below and #651 says we need 145+. Maybe tutorial and README needs an update?

$ npx chrome-devtools-mcp@latest --help 
Options:
      --autoConnect             If specified, automatically connects to a browser (Chrome 145+) running in the user data
                                directory identified by the channel param. Requires remote debugging being enabled in
                                Chrome here: chrome://inspect/#remote-debugging.              [boolean] [default: false]

[OrKoN]

Chrome 144 is the version that autoConnected is expected to work with because the support was landed into the 144 branch while initially it landed in the 145 branch. The docs were updated now. The Protocol Monitor in DevTools would not show any traffic for the MCP scenario as it is completely unrelated.

Could anyone please provide details about the open tabs/extensions in the browser?

[yotahk]

Thanks for the response. For my case, it reproduces without any open tabs/extensions:

• Create a new Chrome user profile (no extensions)
• Open a new tab (chrome://newtab)
• Run npx @modelcontextprotocol/inspector npx chrome-devtools-mcp@latest --auto-connect
• When UI opens click Connect and then List tools and then pick the list_pages tool and send the command.

Results with "Network.enable timed out. Increase the 'protocolTimeout' setting in launch/connect calls for a higher timeout if needed." after waiting for few minutes.

Chrome DevTools MCP version v0.13.0

Chrome version Version 144.0.7559.60 (Official Build) (arm64)

Node version 24.11.0

Operating system macOS 26.2

[OrKoN]

@yotahk thanks for the details! Do you have a single profile in this instance or multiple browser profiles?

[ProjectBetelgeuse]

@yotahk thanks for the details! Do you have a single profile in this instance or multiple browser profiles?

That's reminds me. I do have multiple profile in my chrome.

[yotahk]

I have multiple profiles in my chrome.

[OrKoN]

Cross-posting the note from the docs:

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.

It might be a different profile that Chrome considers the default is picked and some content like extensions/pages hits the a pre-existing issue with Puppeteer. I am not able to reproduce in my profiles.

[OrKoN]

Related https://github.com/ChromeDevTools/chrome-devtools-mcp/issues/694

[OrKoN]

Could you please try the following?

1. Locate the default profile (it's the one launched by Chrome if the profile selection dialog is set to skipped on startup I believe).
2. Have one test page open and disable extensions in the default profile.
3. Try to auto-connect.

Does it make any difference?

[OrKoN]

I also use multiple profiles and I see the following:

1. Multiple profiles open, the connection is successfully established with the default profile.
2. Default profile open only, the connection is successfully established with the default profile.
3. Non-default profile open and other profiles are closed, the connection is successfully established with the non-default profile.

So I think the issue is probably some unexpected content for Puppeteer in the default profile (which might not be very clear with multiple profiles running at the same time).

[yotahk]

1. Locate the default profile (it's the one launched by Chrome if the profile selection dialog is set to skipped on startup I believe).
2. Have one test page open and disable extensions in the default profile.
3. Try to auto-connect.

This worked for me! Also, I tried opening at least one window for each profiles without disabling extensions, also worked. Same as your observations.

So, this seems to be a practical workaround:

1. Open at least one window for each profiles
2. "Hide" unused windows or move them to other desktops

[zzh948498]

I also use multiple profiles and I see the following:

1. Multiple profiles open, the connection is successfully established with the default profile.
2. Default profile open only, the connection is successfully established with the default profile.
3. Non-default profile open and other profiles are closed, the connection is successfully established with the non-default profile.

So I think the issue is probably some unexpected content for Puppeteer in the default profile (which might not be very clear with multiple profiles running at the same time).

I've figured out how to reproduce this issue. It seems that the MCP connection depends on all tabs being fully loaded. My browser is configured to "Continue where you left off" (restore previous session on startup). The restored tabs from the previous session remain in an unloaded/suspended state until clicked, which causes the MCP to get stuck. Once I click on and activate those tabs, the issue resolves.

These tabs need to be clicked again to activate.

[OrKoN]

Thanks @zzh948498 I think this is the same issue as https://github.com/puppeteer/puppeteer/issues/12808 which is more important now given the use cases of using automation tools on regular profiles.