1. 为什么 WSL2 里的 AI 找不到 Windows 的 Chrome很多人现在的开发环境是这样的代码放在 WSL2 里AI agent 也跑在 WSL2 里但日常用的浏览器还是 Windows 桌面上的 Chrome。这个组合本身没问题问题出在“浏览器接管”这一步。chrome-devtools-mcp 是一个让 AI 通过 Chrome DevTools Protocol 直接操作浏览器的 MCP 服务端。它的默认行为是在本地环境里自己去找一个 Chrome 拉起来。放在纯 Linux 或者纯 Windows 环境里这套逻辑没问题。但放在 WSL2 里它会在 Linux 文件系统里找 Chrome结果要么找不到要么拉起来一个没有图形界面的残缺实例要么 MCP 进程启动了但始终连不上 Windows 那边真正在跑的浏览器。我试过直接让 MCP 自己找浏览器日志里反复出现连接超时排查半天才发现它根本没意识到浏览器在另一个操作系统里。WSL2 虽然和 Windows 共享内核但网络命名空间、文件系统、进程空间都是隔离的AI 在 WSL2 里看到的localhost和 Windows 的localhost不是一回事。更稳的思路不是让工具自己去猜浏览器在哪而是把链路拆开各管一段Windows 侧手动启动一个专门给调试用的 Chrome固定远程调试端口使用独立的 user-data-dirWSL2 侧的 chrome-devtools-mcp 只负责通过--browser-url连过去不负责启动浏览器。这样职责清晰Windows 管浏览器进程WSL2 管 AI 和 MCP 服务端中间靠一个 HTTP 调试端口通信。出问题时也能快速定位是浏览器没起来、端口不通、还是 MCP 配置写错了。这套方案适合谁适合在 WSL2 里跑 Codex、Cline、Claude Code 等 AI 编码工具同时希望 AI 能直接打开页面、读 Console、看 Network、做截图和表单操作的开发者。下面从环境确认开始一步步给出可复制的配置。2. 前置确认Node 版本、WSL 网络模式与 Chrome 安装开始配之前先把三个前提确认清楚否则后面报错会很难判断是哪一层的问题。第一Windows 侧已经安装 Google Chrome。chrome-devtools-mcp 官方明确支持的是 Google Chrome 和 Chrome for Testing。为了减少变量下面统一按 Google Chrome 来写路径默认在C:\Program Files\Google\Chrome\Application\chrome.exe。如果你用的是其他 Chromium 内核浏览器参数逻辑类似但路径和部分行为可能有差异。第二WSL2 里有可用的 Node.js、npm、npx。按当前 READMEchrome-devtools-mcp 要求 Node.js 为 20.19 或更高的维护中 LTS。先在 WSL2 里执行node -v npm -v npx -y chrome-devtools-mcplatest --help如果node -v低于 20.19先升级 Node。如果npx这条命令报错先别继续配浏览器把 Node 环境理顺再说。这一步能跑通说明 MCP 服务端本身在 WSL2 里是可执行的。第三确认当前 WSL2 走的是 mirrored 还是 NAT 网络模式。这个决定了后面写127.0.0.1还是 Windows 宿主机 IP。如果你用的是 mirrored 模式WSL2 一般可以直接访问 Windows 侧的127.0.0.1curl http://127.0.0.1:9922/json/version如果你还是 NAT 模式就需要先查 Windows 宿主机 IPip route show | grep -i default | awk { print $3 }后面的地址都改成http://Windows宿主机IP:9922。如果你打算切到 mirrored可以在 Windows 用户目录下的.wslconfig里写[wsl2] networkingModemirrored保存后执行wsl --shutdown然后重新打开 WSL。mirrored 模式下 WSL2 和 Windows 共享网络接口访问127.0.0.1就能直达 Windows 侧服务配置会简单很多。但要注意切换网络模式后所有依赖 IP 的配置都要重新确认。这三件事确认完再往下走。很多人卡住不是因为 MCP 配置错而是 Node 版本不够或者网络模式没搞清导致后面每一步都在猜。3. 可复制配置Windows 启动调试 Chrome WSL2 配置 MCP这一节是核心分两步先在 Windows 上启动一个专门给调试用的 Chrome再在 WSL2 里配置 chrome-devtools-mcp 和 Codex。3.1 Windows 侧启动调试 ChromeChrome 官方从 Chrome 136 开始收紧了远程调试开关的规则如果你对默认数据目录启用--remote-debugging-port或--remote-debugging-pipe这些开关不会生效。要让远程调试真正打开必须同时指定一个非默认的--user-data-dir。所以现在不要再用这种旧命令chrome.exe --remote-debugging-port9922它在新版本 Chrome 里很可能根本不起作用。正确做法是单独起一个专门给调试用的 Chrome 实例。PowerShell 用下面这条 C:\Program Files\Google\Chrome\Application\chrome.exe --remote-debugging-port9922 --user-data-dir$env:TEMP\chrome-devtools-mcp-profile如果你习惯用 cmd对应命令是C:\Program Files\Google\Chrome\Application\chrome.exe --remote-debugging-port9922 --user-data-dir%TEMP%\chrome-devtools-mcp-profile如果你的 Chrome 不在默认路径把可执行文件路径换成你自己的实际位置其他参数不要删。长期用的话最省事的做法是做一个 Windows 快捷方式目标写成C:\Program Files\Google\Chrome\Application\chrome.exe --remote-debugging-port9922 --user-data-dir%TEMP%\chrome-devtools-mcp-profile这个 Chrome 最好只给 AI 和调试用不要和日常浏览混用。独立 user-data-dir 的好处是不会污染你的日常书签和登录态也不会因为日常 Chrome 已经在运行而导致调试实例启动失败。3.2 WSL2 侧配置 chrome-devtools-mcp浏览器启动后先不要急着配 Codex。先在 WSL2 里确认调试端口真的通了。Chrome DevTools Protocol 官方文档里明确提到远程调试启动后可以访问/json/version返回内容里会带webSocketDebuggerUrl。mirrored 模式直接测curl http://127.0.0.1:9922/json/versionNAT 模式先查宿主机 IP 再测HOST_IP$(ip route show | grep -i default | awk { print $3 }) curl http://${HOST_IP}:9922/json/version如果返回 JSON 且里面有webSocketDebuggerUrl说明浏览器这边已经准备好了。如果这一步不通先别碰 MCP问题还停留在浏览器或网络层。确认端口通之后配置 MCP。很多 AI 客户端都支持标准 MCP JSON 配置写法类似这样{ mcpServers: { chrome-devtools: { command: npx, args: [ -y, chrome-devtools-mcplatest, --browser-urlhttp://127.0.0.1:9922 ] } } }如果你现在走的是 NAT就把地址改成http://Windows宿主机IP:9922。这里真正关键的就一个参数--browser-urlhttp://127.0.0.1:9922。它的意思很直接不要自己去找浏览器直接连这个已经开好的 Chrome。3.3 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-mcplatest, --browser-urlhttp://127.0.0.1:9922]如果你是 NAT 模式就把地址改成宿主机 IP。有些环境下npx 第一次运行包时会弹确认。如果你碰到 Codex 一直卡在启动 MCP或者日志看起来像是在等确认可以改成[mcp_servers.chrome-devtools] command npx args [-y, chrome-devtools-mcplatest, --browser-urlhttp://127.0.0.1:9922]如果你不想手改文件也可以直接在 WSL2 里执行codex mcp add chrome-devtools -- npx chrome-devtools-mcplatest --browser-urlhttp://127.0.0.1:9922执行完以后最好再打开~/.codex/config.toml看一眼确认已经写进去。三件套要写全Base URL 是http://127.0.0.1:9922Key 这里不需要Model ID 由 Codex 自身配置决定MCP 只负责浏览器连接。4. 验证请求从 curl 到 AI 实际操控页面配置写完不代表通了建议按下面顺序验证不要一上来就给 AI 下复杂任务。第一步确认包本身能跑起来npx -y chrome-devtools-mcplatest --help能打印帮助信息说明 MCP 服务端在 WSL2 里可执行。第二步确认调试端口还通着curl http://127.0.0.1:9922/json/version返回内容里应该有Browser、Protocol-Version、webSocketDebuggerUrl等字段。如果这一步失败回到第 3 节检查 Chrome 启动参数和网络模式。第三步重启 Codex或者让你的 AI 客户端重新加载 MCP 配置。很多客户端不会热加载 MCP改完config.toml必须重启进程。第四步给 AI 一个很简单的任务比如打开 https://example.com查看 Console 是否有报错再检查一下 Network 请求。这个阶段先看两件事AI 能不能把页面打开AI 能不能拿到浏览器里的调试信息。这两件事通了后面的点击、截图、表单、性能分析基本就是顺着往下做。如果 AI 能打开页面但拿不到 Console检查一下是不是连到了错误的 target。Chrome 调试端口会暴露多个 page targetMCP 需要选对当前活动标签页。如果 AI 完全没反应看 Codex 日志里 MCP 是否启动成功常见的是 npx 卡在第一次下载。验证通过后你可以让 AI 做更复杂的操作比如打开 https://example.com截图保存到 /tmp/example.png然后读取页面标题。截图能落盘、标题能返回说明整条链路从 WSL2 到 Windows Chrome 已经完全打通。5. 常见报错排查401、local proxy failed、reading choices、OAuth这一节对照真实报错来排查。不同报错对应不同层的问题不要混在一起猜。报错一401 Unauthorized如果你在 MCP 配置里加了额外的认证头或者客户端要求 API Key但 chrome-devtools-mcp 本身不需要 Key。401 通常出现在你同时配置了其他需要鉴权的 MCP 服务端或者把 TaoToken 的 API Key 误填到了浏览器 MCP 里。检查config.toml里[mcp_servers.chrome-devtools]这一段只保留command和args不要加env里的 Key。报错二local proxy failed或连接被拒绝这是 WSL2 网络层最典型的报错。原因通常是Chrome 没启动、端口没监听、或者 WSL2 和 Windows 网络不通。按顺序检查# 1. Windows 侧确认端口在监听 netstat -ano | findstr 9922 # 2. WSL2 侧确认能访问 curl -v http://127.0.0.1:9922/json/version如果 Windows 侧netstat没有输出说明 Chrome 没按带参数的命令启动或者被已有 Chrome 实例拦截了。先关掉所有 Chrome再用独立 user-data-dir 启动。报错三reading choices或 JSON 解析失败这个报错通常出现在 MCP 客户端读取服务端返回时。chrome-devtools-mcp 启动后会输出 JSON-RPC 消息如果 npx 在第一次运行时输出了额外的下载日志会污染 stdout导致客户端解析失败。解决办法是在 args 里加-y并确保 npx 缓存已经预热npx -y chrome-devtools-mcplatest --help先手动跑一次让包下载完成再重启 Codex。报错四OAuth相关报错chrome-devtools-mcp 本身不走 OAuth。如果你看到 OAuth 报错大概率是 Codex 或其他 MCP 客户端在尝试认证另一个服务端。检查config.toml里是否有多个[mcp_servers.*]逐个确认哪个需要 OAuth、哪个不需要。浏览器 MCP 只需要--browser-url。报错五Codex 启动但 MCP 没加载先看~/.codex/config.toml路径是不是写对了TOML 语法有没有写错改完配置后 Codex 是否已经重启npx 是否卡在第一次安装确认。可以用codex mcp list查看当前已注册的 MCP 服务端。如果端口换了配置也要一起跟着改。比如你 Windows 上启动的是--remote-debugging-port9922那 WSL2 里的 curl、--browser-url、Codex 的config.toml都必须写 9922。不要一边启动 9922一边配置 9222。还有一点要单独提醒WSL 的确可以从 Linux 命令行直接启动 Windows 程序但在这个问题上更稳的方式还是 Windows 负责启动 ChromeWSL2 负责运行 AI 和 MCPchrome-devtools-mcp 只负责连接。这样职责清楚问题也更好定位。6. 接入 TaoToken让 Codex 的模型调用与浏览器控制各司其职浏览器链路打通后Codex 本身还需要一个稳定的模型调用入口。TaoToken 提供 OpenAI 兼容的 API 接入适合在 WSL2 里给 Codex、Cline 等工具做模型后端。它的 API 地址是https://taotoken.net/api不附加 UTM 参数直接用于配置。在 Codex 的配置里模型调用和 MCP 浏览器控制是两套独立配置。模型侧配置 API Key 和 Base URLMCP 侧只配--browser-url。两者不要混在一起否则排查时会互相干扰。如果你用的是 Codex可以在~/.codex/config.toml里同时保留模型配置和 MCP 配置model gpt-4o model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY [mcp_servers.chrome-devtools] command npx args [-y, chrome-devtools-mcplatest, --browser-urlhttp://127.0.0.1:9922]然后在 WSL2 里设置环境变量export TAOTOKEN_API_KEY你的KeyKey 可以在 TaoToken 控制台的 API Keys 页面创建https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite配置完成后Codex 用 TaoToken 做模型推理chrome-devtools-mcp 用--browser-url连 Windows Chrome两条链路互不依赖。模型侧出问题看 API Key 和 Base URL浏览器侧出问题看端口和网络模式。如果你更习惯用图形界面调试模型对话可以打开模型对话页面直接测试https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite对于长期在 WSL2 里跑编码 Agent 的场景Coding Plan 提供了更稳定的调用额度https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite接入文档里有完整的 Base URL 和参数说明https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite如果你用的是 Claude Code 或 Anthropic 兼容客户端接入方式参考https://taotoken.net/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentclaudecodeutm_campaignrewrite整个链路的核心思路就一句话Windows 管浏览器WSL2 管 AITaoToken 管模型调用chrome-devtools-mcp 只负责连接已经存在的浏览器。把这几件事拆开以后配置会清楚很多排障也会轻松很多。
别被环境隔离骗了：WSL2 里的 AI，照样能直接控制 Windows Chrome
1. 为什么 WSL2 里的 AI 找不到 Windows 的 Chrome很多人现在的开发环境是这样的代码放在 WSL2 里AI agent 也跑在 WSL2 里但日常用的浏览器还是 Windows 桌面上的 Chrome。这个组合本身没问题问题出在“浏览器接管”这一步。chrome-devtools-mcp 是一个让 AI 通过 Chrome DevTools Protocol 直接操作浏览器的 MCP 服务端。它的默认行为是在本地环境里自己去找一个 Chrome 拉起来。放在纯 Linux 或者纯 Windows 环境里这套逻辑没问题。但放在 WSL2 里它会在 Linux 文件系统里找 Chrome结果要么找不到要么拉起来一个没有图形界面的残缺实例要么 MCP 进程启动了但始终连不上 Windows 那边真正在跑的浏览器。我试过直接让 MCP 自己找浏览器日志里反复出现连接超时排查半天才发现它根本没意识到浏览器在另一个操作系统里。WSL2 虽然和 Windows 共享内核但网络命名空间、文件系统、进程空间都是隔离的AI 在 WSL2 里看到的localhost和 Windows 的localhost不是一回事。更稳的思路不是让工具自己去猜浏览器在哪而是把链路拆开各管一段Windows 侧手动启动一个专门给调试用的 Chrome固定远程调试端口使用独立的 user-data-dirWSL2 侧的 chrome-devtools-mcp 只负责通过--browser-url连过去不负责启动浏览器。这样职责清晰Windows 管浏览器进程WSL2 管 AI 和 MCP 服务端中间靠一个 HTTP 调试端口通信。出问题时也能快速定位是浏览器没起来、端口不通、还是 MCP 配置写错了。这套方案适合谁适合在 WSL2 里跑 Codex、Cline、Claude Code 等 AI 编码工具同时希望 AI 能直接打开页面、读 Console、看 Network、做截图和表单操作的开发者。下面从环境确认开始一步步给出可复制的配置。2. 前置确认Node 版本、WSL 网络模式与 Chrome 安装开始配之前先把三个前提确认清楚否则后面报错会很难判断是哪一层的问题。第一Windows 侧已经安装 Google Chrome。chrome-devtools-mcp 官方明确支持的是 Google Chrome 和 Chrome for Testing。为了减少变量下面统一按 Google Chrome 来写路径默认在C:\Program Files\Google\Chrome\Application\chrome.exe。如果你用的是其他 Chromium 内核浏览器参数逻辑类似但路径和部分行为可能有差异。第二WSL2 里有可用的 Node.js、npm、npx。按当前 READMEchrome-devtools-mcp 要求 Node.js 为 20.19 或更高的维护中 LTS。先在 WSL2 里执行node -v npm -v npx -y chrome-devtools-mcplatest --help如果node -v低于 20.19先升级 Node。如果npx这条命令报错先别继续配浏览器把 Node 环境理顺再说。这一步能跑通说明 MCP 服务端本身在 WSL2 里是可执行的。第三确认当前 WSL2 走的是 mirrored 还是 NAT 网络模式。这个决定了后面写127.0.0.1还是 Windows 宿主机 IP。如果你用的是 mirrored 模式WSL2 一般可以直接访问 Windows 侧的127.0.0.1curl http://127.0.0.1:9922/json/version如果你还是 NAT 模式就需要先查 Windows 宿主机 IPip route show | grep -i default | awk { print $3 }后面的地址都改成http://Windows宿主机IP:9922。如果你打算切到 mirrored可以在 Windows 用户目录下的.wslconfig里写[wsl2] networkingModemirrored保存后执行wsl --shutdown然后重新打开 WSL。mirrored 模式下 WSL2 和 Windows 共享网络接口访问127.0.0.1就能直达 Windows 侧服务配置会简单很多。但要注意切换网络模式后所有依赖 IP 的配置都要重新确认。这三件事确认完再往下走。很多人卡住不是因为 MCP 配置错而是 Node 版本不够或者网络模式没搞清导致后面每一步都在猜。3. 可复制配置Windows 启动调试 Chrome WSL2 配置 MCP这一节是核心分两步先在 Windows 上启动一个专门给调试用的 Chrome再在 WSL2 里配置 chrome-devtools-mcp 和 Codex。3.1 Windows 侧启动调试 ChromeChrome 官方从 Chrome 136 开始收紧了远程调试开关的规则如果你对默认数据目录启用--remote-debugging-port或--remote-debugging-pipe这些开关不会生效。要让远程调试真正打开必须同时指定一个非默认的--user-data-dir。所以现在不要再用这种旧命令chrome.exe --remote-debugging-port9922它在新版本 Chrome 里很可能根本不起作用。正确做法是单独起一个专门给调试用的 Chrome 实例。PowerShell 用下面这条 C:\Program Files\Google\Chrome\Application\chrome.exe --remote-debugging-port9922 --user-data-dir$env:TEMP\chrome-devtools-mcp-profile如果你习惯用 cmd对应命令是C:\Program Files\Google\Chrome\Application\chrome.exe --remote-debugging-port9922 --user-data-dir%TEMP%\chrome-devtools-mcp-profile如果你的 Chrome 不在默认路径把可执行文件路径换成你自己的实际位置其他参数不要删。长期用的话最省事的做法是做一个 Windows 快捷方式目标写成C:\Program Files\Google\Chrome\Application\chrome.exe --remote-debugging-port9922 --user-data-dir%TEMP%\chrome-devtools-mcp-profile这个 Chrome 最好只给 AI 和调试用不要和日常浏览混用。独立 user-data-dir 的好处是不会污染你的日常书签和登录态也不会因为日常 Chrome 已经在运行而导致调试实例启动失败。3.2 WSL2 侧配置 chrome-devtools-mcp浏览器启动后先不要急着配 Codex。先在 WSL2 里确认调试端口真的通了。Chrome DevTools Protocol 官方文档里明确提到远程调试启动后可以访问/json/version返回内容里会带webSocketDebuggerUrl。mirrored 模式直接测curl http://127.0.0.1:9922/json/versionNAT 模式先查宿主机 IP 再测HOST_IP$(ip route show | grep -i default | awk { print $3 }) curl http://${HOST_IP}:9922/json/version如果返回 JSON 且里面有webSocketDebuggerUrl说明浏览器这边已经准备好了。如果这一步不通先别碰 MCP问题还停留在浏览器或网络层。确认端口通之后配置 MCP。很多 AI 客户端都支持标准 MCP JSON 配置写法类似这样{ mcpServers: { chrome-devtools: { command: npx, args: [ -y, chrome-devtools-mcplatest, --browser-urlhttp://127.0.0.1:9922 ] } } }如果你现在走的是 NAT就把地址改成http://Windows宿主机IP:9922。这里真正关键的就一个参数--browser-urlhttp://127.0.0.1:9922。它的意思很直接不要自己去找浏览器直接连这个已经开好的 Chrome。3.3 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-mcplatest, --browser-urlhttp://127.0.0.1:9922]如果你是 NAT 模式就把地址改成宿主机 IP。有些环境下npx 第一次运行包时会弹确认。如果你碰到 Codex 一直卡在启动 MCP或者日志看起来像是在等确认可以改成[mcp_servers.chrome-devtools] command npx args [-y, chrome-devtools-mcplatest, --browser-urlhttp://127.0.0.1:9922]如果你不想手改文件也可以直接在 WSL2 里执行codex mcp add chrome-devtools -- npx chrome-devtools-mcplatest --browser-urlhttp://127.0.0.1:9922执行完以后最好再打开~/.codex/config.toml看一眼确认已经写进去。三件套要写全Base URL 是http://127.0.0.1:9922Key 这里不需要Model ID 由 Codex 自身配置决定MCP 只负责浏览器连接。4. 验证请求从 curl 到 AI 实际操控页面配置写完不代表通了建议按下面顺序验证不要一上来就给 AI 下复杂任务。第一步确认包本身能跑起来npx -y chrome-devtools-mcplatest --help能打印帮助信息说明 MCP 服务端在 WSL2 里可执行。第二步确认调试端口还通着curl http://127.0.0.1:9922/json/version返回内容里应该有Browser、Protocol-Version、webSocketDebuggerUrl等字段。如果这一步失败回到第 3 节检查 Chrome 启动参数和网络模式。第三步重启 Codex或者让你的 AI 客户端重新加载 MCP 配置。很多客户端不会热加载 MCP改完config.toml必须重启进程。第四步给 AI 一个很简单的任务比如打开 https://example.com查看 Console 是否有报错再检查一下 Network 请求。这个阶段先看两件事AI 能不能把页面打开AI 能不能拿到浏览器里的调试信息。这两件事通了后面的点击、截图、表单、性能分析基本就是顺着往下做。如果 AI 能打开页面但拿不到 Console检查一下是不是连到了错误的 target。Chrome 调试端口会暴露多个 page targetMCP 需要选对当前活动标签页。如果 AI 完全没反应看 Codex 日志里 MCP 是否启动成功常见的是 npx 卡在第一次下载。验证通过后你可以让 AI 做更复杂的操作比如打开 https://example.com截图保存到 /tmp/example.png然后读取页面标题。截图能落盘、标题能返回说明整条链路从 WSL2 到 Windows Chrome 已经完全打通。5. 常见报错排查401、local proxy failed、reading choices、OAuth这一节对照真实报错来排查。不同报错对应不同层的问题不要混在一起猜。报错一401 Unauthorized如果你在 MCP 配置里加了额外的认证头或者客户端要求 API Key但 chrome-devtools-mcp 本身不需要 Key。401 通常出现在你同时配置了其他需要鉴权的 MCP 服务端或者把 TaoToken 的 API Key 误填到了浏览器 MCP 里。检查config.toml里[mcp_servers.chrome-devtools]这一段只保留command和args不要加env里的 Key。报错二local proxy failed或连接被拒绝这是 WSL2 网络层最典型的报错。原因通常是Chrome 没启动、端口没监听、或者 WSL2 和 Windows 网络不通。按顺序检查# 1. Windows 侧确认端口在监听 netstat -ano | findstr 9922 # 2. WSL2 侧确认能访问 curl -v http://127.0.0.1:9922/json/version如果 Windows 侧netstat没有输出说明 Chrome 没按带参数的命令启动或者被已有 Chrome 实例拦截了。先关掉所有 Chrome再用独立 user-data-dir 启动。报错三reading choices或 JSON 解析失败这个报错通常出现在 MCP 客户端读取服务端返回时。chrome-devtools-mcp 启动后会输出 JSON-RPC 消息如果 npx 在第一次运行时输出了额外的下载日志会污染 stdout导致客户端解析失败。解决办法是在 args 里加-y并确保 npx 缓存已经预热npx -y chrome-devtools-mcplatest --help先手动跑一次让包下载完成再重启 Codex。报错四OAuth相关报错chrome-devtools-mcp 本身不走 OAuth。如果你看到 OAuth 报错大概率是 Codex 或其他 MCP 客户端在尝试认证另一个服务端。检查config.toml里是否有多个[mcp_servers.*]逐个确认哪个需要 OAuth、哪个不需要。浏览器 MCP 只需要--browser-url。报错五Codex 启动但 MCP 没加载先看~/.codex/config.toml路径是不是写对了TOML 语法有没有写错改完配置后 Codex 是否已经重启npx 是否卡在第一次安装确认。可以用codex mcp list查看当前已注册的 MCP 服务端。如果端口换了配置也要一起跟着改。比如你 Windows 上启动的是--remote-debugging-port9922那 WSL2 里的 curl、--browser-url、Codex 的config.toml都必须写 9922。不要一边启动 9922一边配置 9222。还有一点要单独提醒WSL 的确可以从 Linux 命令行直接启动 Windows 程序但在这个问题上更稳的方式还是 Windows 负责启动 ChromeWSL2 负责运行 AI 和 MCPchrome-devtools-mcp 只负责连接。这样职责清楚问题也更好定位。6. 接入 TaoToken让 Codex 的模型调用与浏览器控制各司其职浏览器链路打通后Codex 本身还需要一个稳定的模型调用入口。TaoToken 提供 OpenAI 兼容的 API 接入适合在 WSL2 里给 Codex、Cline 等工具做模型后端。它的 API 地址是https://taotoken.net/api不附加 UTM 参数直接用于配置。在 Codex 的配置里模型调用和 MCP 浏览器控制是两套独立配置。模型侧配置 API Key 和 Base URLMCP 侧只配--browser-url。两者不要混在一起否则排查时会互相干扰。如果你用的是 Codex可以在~/.codex/config.toml里同时保留模型配置和 MCP 配置model gpt-4o model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY [mcp_servers.chrome-devtools] command npx args [-y, chrome-devtools-mcplatest, --browser-urlhttp://127.0.0.1:9922]然后在 WSL2 里设置环境变量export TAOTOKEN_API_KEY你的KeyKey 可以在 TaoToken 控制台的 API Keys 页面创建https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi_keysutm_campaignrewrite配置完成后Codex 用 TaoToken 做模型推理chrome-devtools-mcp 用--browser-url连 Windows Chrome两条链路互不依赖。模型侧出问题看 API Key 和 Base URL浏览器侧出问题看端口和网络模式。如果你更习惯用图形界面调试模型对话可以打开模型对话页面直接测试https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_contentmodel_chatutm_campaignrewrite对于长期在 WSL2 里跑编码 Agent 的场景Coding Plan 提供了更稳定的调用额度https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding_planutm_campaignrewrite接入文档里有完整的 Base URL 和参数说明https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_contentdocutm_campaignrewrite如果你用的是 Claude Code 或 Anthropic 兼容客户端接入方式参考https://taotoken.net/ClaudeCodeAnthropic?utm_sourcetaotoken_aicg_blog_endutm_contentclaudecodeutm_campaignrewrite整个链路的核心思路就一句话Windows 管浏览器WSL2 管 AITaoToken 管模型调用chrome-devtools-mcp 只负责连接已经存在的浏览器。把这几件事拆开以后配置会清楚很多排障也会轻松很多。
