Site icon Efficient Coder

Fix chrome-devtools-mcp Timeout Issues on Windows: Ultimate Guide

高效码农

Fixing MCP Client Timeout When Using chrome-devtools-mcp on Windows

When integrating Model Context Protocol (MCP) with Chrome DevTools, many developers encounter a frustrating issue:


MCP client for `chrome-devtools` failed to start: request timed out

This blog post explains the root causes, step-by-step troubleshooting, and the final working solution on Windows.
If you’re struggling with no listening ports or Chrome executable path mismatches, this guide will save you hours of debugging.

🔍 Background: Why Does MCP Timeout Happen?

The MCP (Model Context Protocol) client allows AI models and developer tools to connect to Chrome DevTools for debugging, inspection, and data extraction.

However, when running on Windows, MCP often fails to find or launch Chrome because:

  1. The Chrome executable path does not match MCP’s internal lookup.
  2. No DevTools WebSocket debugging port (9223) is exposed.
  3. chrome-devtools-mcp cannot properly attach to the Chrome instance.

This results in timeouts and no active TCP listener on localhost:9223.

🛠️ Step-by-Step Troubleshooting

1. Verify MCP Client Installation

Run the following to check if the package is installed globally:

where chrome-devtools-mcp

If nothing is returned, install it:

npm install -g chrome-devtools-mcp

2. Check Chrome Debugging Port

Confirm if Chrome is listening on port 9223:

Get-NetTCPConnection -State Listen | Where-Object { $_.LocalPort -eq 9223 }
  • If no output appears, Chrome is not running with remote debugging enabled.

3. Start Chrome With Remote Debugging

Manually launch Chrome:

chrome.exe --remote-debugging-port=9223

If Chrome cannot be found, it means MCP’s lookup path is broken (common on Windows Server).

4. Inspect Logs

To capture errors:

Get-Content C:\temp\mcp-manual.log -Tail 200

Typical log output includes:

chrome-devtools-mcp exposes content of the browser instance to the MCP clients...
Avoid sharing sensitive or personal information that you do not want to share.

This indicates MCP is running, but cannot attach to Chrome.

✅ Final Solution (Working Fix on Windows)

The root cause: MCP looks for Chrome inside the Local AppData path, not C:\Program Files.

Steps to Fix:

  1. Copy your Chrome installation to the expected directory:
C:\Users\Administrator\AppData\Local\Google\Chrome\Application
  1. Create a symbolic link so that MCP can resolve the executable:
New-Item -ItemType SymbolicLink `
   -Path "$env:LOCALAPPDATA\Google\Chrome\Application\chrome.exe" `
   -Target "C:\Program Files\Google\Chrome\Application\chrome.exe"
  1. In the MCP project root, create a junction pointing to:
C:\Users\Administrator\AppData\Local

This ensures DevTools follows its fixed lookup logic and successfully finds chrome.exe.

After applying this solution, running:

Get-NetTCPConnection -State Listen | Where-Object { $_.LocalPort -eq 9223 }

should now display an active listener for Chrome DevTools.

📌 Key Takeaways

  • MCP relies on Chrome’s AppData path in Windows, not Program Files.
  • Without fixing the path mismatch, MCP will always timeout.
  • Symbolic links are a clean way to “trick” MCP into finding the correct Chrome binary.

❓ FAQ

Q1: Why does MCP default to AppData instead of Program Files?
Because MCP inherits lookup rules from DevTools’ internal logic, which assumes a per-user installation.

Q2: Can I change MCP’s lookup path directly?
Not easily. MCP has a hardcoded search path, so symbolic links are the simplest fix.

Q3: Is it safe to expose port 9223?
Yes, but keep in mind it allows remote debugging. Do not expose it to untrusted networks.

📖 Related Resources

🏆 Conclusion

If your MCP client fails to start with Chrome DevTools on Windows, the most reliable fix is to symlink Chrome.exe into AppData.

Once configured, DevTools attaches smoothly, and your AI/DevTools integration becomes stable.

This simple trick saves hours of trial and error, and ensures your MCP + Chrome setup works seamlessly.

Exit mobile version