摘要
现在很常见的一套开发环境是：代码在 WSL2，AI agent 也跑在 WSL2，但浏览器还是 Windows 里的 Chrome。
问题往往出在浏览器接管这一步。很多工具会先去 Linux 环境里找 Chrome，结果不是没拉起来，就是 MCP 启动了但始终连不上 Windows 这边的浏览器。
这类场景里，更稳的做法不是让工具自己找浏览器，而是把链路拆开：
- Windows 手动启动一个专门给调试用的 Chrome
- 这个 Chrome 打开远程调试端口，比如
9922 - 同时使用单独的
user-data-dir - WSL2 里的
chrome-devtools-mcp只负责通过--browser-url连过去
这样做的好处很直接：问题更少，也更好排。
一、确认环境
开始前先确认三件事。
第一，Windows 侧已经安装 Google Chrome。chrome-devtools-mcp 官方明确支持的是 Google Chrome 和 Chrome for Testing。为了减少变量，下面统一按 Google Chrome 来写。
第二，WSL2 里有可用的 Node.js、npm、npx。按当前 README，chrome-devtools-mcp 要求 Node.js 为 20.19 或更高的维护中 LTS。先在 WSL2 里执行：
node -v
npm -v
npx -y chrome-devtools-mcp@latest --help
如果这里就报错，先别继续配浏览器，先把 Node 环境理顺。
第三，先确认自己现在走的是 mirrored 还是 NAT。因为后面写 127.0.0.1 还是 Windows 宿主机 IP，取决于这个前提。
如果你用的是 mirrored，WSL2 一般可以直接访问：
http://127.0.0.1:9922
如果你还是 NAT，就先在 WSL2 里查宿主机 IP：
ip route show | grep -i default | awk '{ print $3 }'
后面的地址都改成：
http://<Windows宿主机IP>:9922
如果你打算切到 mirrored，可以在 Windows 用户目录下的 .wslconfig 里写：
[wsl2]
networkingMode=mirrored
保存后执行：
wsl --shutdown
然后重新打开 WSL。
二、在 Windows 上启动调试 Chrome
这一节是关键。
Chrome 官方从 Chrome 136 开始收紧了远程调试开关的规则：如果你对默认数据目录启用 --remote-debugging-port 或 --remote-debugging-pipe，这些开关不会生效。要让远程调试真正打开，必须同时指定一个非默认的 --user-data-dir。
所以现在不要再用这种旧命令：
chrome.exe --remote-debugging-port=9922
它在新版本 Chrome 里很可能根本不起作用。
正确做法是单独起一个专门给调试用的 Chrome 实例。
PowerShell 用下面这条：
& "C:\Program Files\Google\Chrome\Application\chrome.exe" `
--remote-debugging-port=9922 `
--user-data-dir="$env:TEMP\chrome-devtools-mcp-profile"
如果你习惯用 cmd，对应命令是：
"C:\Program Files\Google\Chrome\Application\chrome.exe" --remote-debugging-port=9922 --user-data-dir="%TEMP%\chrome-devtools-mcp-profile"
如果你的 Chrome 不在默认路径，把可执行文件路径换成你自己的实际位置，其他参数不要删。
长期用的话，最省事的做法是直接做一个 Windows 快捷方式，目标写成：
"C:\Program Files\Google\Chrome\Application\chrome.exe" --remote-debugging-port=9922 --user-data-dir="%TEMP%\chrome-devtools-mcp-profile"
这个 Chrome 最好只给 AI 和调试用，不要和日常浏览混用。
三、先测端口，再配 MCP
浏览器启动以后，先不要急着配 Codex，也不要急着让 AI 去点页面。
先在 WSL2 里确认调试端口真的通了。Chrome DevTools Protocol 官方文档里明确提到，远程调试启动后可以访问 /json/version，返回内容里会带 webSocketDebuggerUrl。
如果你现在是 mirrored，直接测：
curl http://127.0.0.1:9922/json/version
如果你现在是 NAT，就先查宿主机 IP 再测：
HOST_IP=$(ip route show | grep -i default | awk '{ print $3 }')
curl "http://${HOST_IP}:9922/json/version"
如果这里返回 JSON，而且里面有 webSocketDebuggerUrl，说明浏览器这边已经准备好了。
如果这一步不通，先别碰 MCP。通常问题还停留在浏览器这一层。优先检查：
- Chrome 是不是按带参数的命令启动的
--user-data-dir用的是不是非默认目录- 你当前到底是 mirrored 还是 NAT
.wslconfig改完后有没有执行过wsl --shutdown
四、配置 chrome-devtools-mcp
很多 AI 客户端都支持标准 MCP JSON 配置，写法类似这样：
{
"mcpServers": {
"chrome-devtools": {
"command": "npx",
"args": [
"-y",
"chrome-devtools-mcp@latest",
"--browser-url=http://127.0.0.1:9922"
]
}
}
}
如果你现在走的是 NAT，就把地址改成：
http://<Windows宿主机IP>:9922
这里真正关键的就一个参数：
--browser-url=http://127.0.0.1:9922
它的意思很直接：不要自己去找浏览器，直接连这个已经开好的 Chrome。
五、配置 Codex
如果你用的是 Codex，最直接的方式有两种：直接改 ~/.codex/config.toml，或者用 codex mcp add 加进去。
config.toml 通常在：
~/.codex/config.toml
对大多数人来说，实际路径就是：
/home/<你的用户名>/.codex/config.toml
最直接的配置可以写成：
[mcp_servers.chrome-devtools]
command = "npx"
args = ["chrome-devtools-mcp@latest", "--browser-url=http://127.0.0.1:9922"]
如果你是 NAT 模式，就把地址改成宿主机 IP。
有些环境下，npx 第一次运行包时会弹确认。
如果你碰到 Codex 一直卡在启动 MCP，或者日志看起来像是在等确认，可以改成：
[mcp_servers.chrome-devtools]
command = "npx"
args = ["-y", "chrome-devtools-mcp@latest", "--browser-url=http://127.0.0.1:9922"]
如果你不想手改文件，也可以直接在 WSL2 里执行：
codex mcp add chrome-devtools -- npx chrome-devtools-mcp@latest --browser-url=http://127.0.0.1:9922
执行完以后，最好再打开 ~/.codex/config.toml 看一眼，确认已经写进去。
六、怎么验证是不是已经通了
建议按这个顺序来，不要一上来就给 AI 下复杂任务。
先确认包本身能跑起来：
npx -y chrome-devtools-mcp@latest --help
再确认调试端口还通着：
curl http://127.0.0.1:9922/json/version
然后重启 Codex，或者让你的 AI 客户端重新加载 MCP 配置。
最后给 AI 一个很简单的任务，比如：
打开 https://example.com，查看 Console 是否有报错，再检查一下 Network 请求。
这个阶段先看两件事：
- AI 能不能把页面打开
- AI 能不能拿到浏览器里的调试信息
这两件事通了，后面的点击、截图、表单、性能分析基本就是顺着往下做。
七、几个常见坑
如果 curl 不通，优先排查这几项：
- Chrome 是否真的用了
--remote-debugging-port=9922 - Chrome 是否真的用了非默认
--user-data-dir - 你现在到底是 mirrored 还是 NAT
- Windows 上是否已经关掉旧的调试 Chrome 后重新启动过
如果 Codex 配好了，但看起来没加载 MCP，先看这几件事：
~/.codex/config.toml路径是不是写对了- TOML 语法有没有写错
- 改完配置后，Codex 是否已经重启
npx是否卡在第一次安装确认
如果端口换了，配置也要一起跟着改。
比如你 Windows 上启动的是：
--remote-debugging-port=9922
那 WSL2 里的 curl、--browser-url、Codex 的 config.toml 都必须写 9922。不要一边启动 9922，一边配置 9222。
还有一点要单独提醒。WSL 的确可以从 Linux 命令行直接启动 Windows 程序，但在这个问题上，更稳的方式还是：
- Windows 负责启动 Chrome
- WSL2 负责运行 AI 和 MCP
chrome-devtools-mcp只负责连接
这样职责清楚，问题也更好定位。
结论
WSL2 里跑 AI，Windows 里用 Chrome，这套组合完全能跑通。关键不在于让 AI 自己去猜浏览器在哪，而在于你先把浏览器这一侧固定下来。
也就是四件事：
- Windows 手动启动专用 Chrome
- 固定远程调试端口
- 使用非默认
user-data-dir - WSL2 里的 MCP 和 Codex 只负责连接这个已经存在的浏览器
把这几件事拆开以后，配置会清楚很多，排障也会轻松很多。
评论区