★GPT-5.2-Codex Agent Sandbox 中 chrome-devtools MCP 启动失败的完整排查与修复实录（基于真实问题）★

Snippet

在 GPT-5.2-Codex 的 Agent Sandbox 模式下，chrome-devtools MCP 启动失败且提示 initialize 阶段连接关闭，最终确认根因是使用 Node.js 18 安装更新导致运行时不兼容。切换并使用 Node.js 22 重新安装后，MCP 握手恢复正常，问题彻底解决。

一、问题背景：一个“之前一直正常”的环境为何突然失效？

不少开发者在使用 GPT-5.2-Codex 模型的 Agent Sandbox 模式时，都会遇到一个令人困惑的问题：
同样的机器、同样的项目、同样的使用方式，前一天还能正常启动，第二天却突然报错。

典型报错信息如下：


MCP client for `chrome-devtools` failed to start:
MCP startup failed: handshaking with MCP server failed:
connection closed: initialize response

⚠ MCP startup incomplete (failed: chrome-devtools)

从表面看，这是一个与 Chrome DevTools 或端口相关的问题，但在实际排查过程中，很容易陷入“端口、权限、防火墙、Chrome 版本”的反复尝试中，却始终无法解决。

本文将基于一次完整、真实、可复现的排查过程，系统梳理这个问题的技术本质，并给出明确、可验证的最终解决方案。

二、目标读者与阅读收益

如果你符合以下任一情况，这篇文章将直接解决你的困惑：

🍄

使用 Codex CLI + GPT-5.2-Codex
🍄

启用了 Agent Sandbox
🍄

依赖 chrome-devtools MCP 进行浏览器能力
🍄

遇到 MCP 在 initialize 阶段直接断开的问题
🍄

确认 Chrome 远程调试端口（如 9222）是可访问的

阅读完成后，你将清楚理解：

🍄

MCP 架构中各组件的真实分工
🍄

为什么 Chrome 正常 ≠ MCP 一定能启动
🍄

为什么 Node.js 版本会成为“隐藏杀手”
🍄

如何一次性、低成本地修复并避免再次踩坑

三、技术架构速览：问题发生在哪一层？

在 Agent Sandbox 场景下，完整的调用链路可以简化为：


GPT-5.2-Codex
↓
Agent Sandbox
↓
MCP Client（chrome-devtools）
↓
本地 MCP Server
↓
Chrome DevTools Protocol（CDP）
↓
Chrome（remote debugging）

关键点在于：
你看到的错误，发生在 MCP Client ↔ MCP Server 之间，而不是 Chrome ↔ CDP 之间。

这一点，是后续所有判断的基础。

四、初步验证：Chrome 与端口是否真的没问题？

在本次案例中，已经完成了以下验证步骤：

1. Chrome 可正常启动

通过完整路径启动 Chrome，并显式指定远程调试端口：

"C:\Program Files\Google\Chrome\Application\chrome.exe" ^
  --remote-debugging-port=9222 ^
  --user-data-dir="C:\temp\chrome-codex"

2. DevTools 端口可访问

在浏览器中访问：

http://localhost:9222/json

返回结果为 标准 JSON 数据，这说明：

🍄

Chrome 已正确开启远程调试
🍄

端口 9222 未被占用
🍄

本地网络与权限无异常

至此，可以 100% 排除 Chrome 与 CDP 层的问题。

五、关键症状分析：为什么 MCP 会在 initialize 阶段“直接断开”？

MCP 的启动过程并不是简单的 TCP 连接，而是一个明确的协议流程：

MCP Client 建立连接
发送 initialize 请求（包含 schema、能力描述等）
MCP Server 校验并返回响应
双方进入可用状态

本次问题的核心特征是：

🍄

TCP 连接可以建立
🍄

MCP Server 在 initialize 阶段直接关闭连接
🍄

客户端只能收到 connection closed

这意味着什么？

“

意味着 MCP Server 在“解析 initialize 请求”时发生了不可恢复的错误。

而这种错误，往往不会以友好的日志形式返回给客户端。

六、排除法：哪些常见原因已经被否定？

在本案例中，以下常见原因已被逐一排除：

可能原因	验证结果
Chrome 未启动	已启动
远程调试端口未开启	已开启
端口被占用	未占用
防火墙 / 权限问题	本地访问正常
Codex CLI 无法启动	CLI 正常
Sandbox 模式整体失效	仅 chrome-devtools MCP 失败

在 MCP 架构下，当以上条件全部成立时，唯一高概率的剩余变量，就是运行 MCP Server 的运行时环境。

七、最终定位：Node.js 版本不兼容

经过回溯环境变更历史，发现一个关键信息：

“

最近一次 Codex / Agent Sandbox 的更新，是在 Node.js 18 环境下完成的。

而在问题解决后，通过以下方式恢复正常：

🍄

切换到 Node.js 22
🍄

使用 Node.js 22 重新安装 Codex / MCP 相关组件
🍄

不再修改任何其他配置

结果：

🍄

chrome-devtools MCP 成功 initialize
🍄

Agent Sandbox 正常启动
🍄

错误不再出现

这直接验证了根因：

“

Node.js 18 与当前版本的 chrome-devtools MCP Server 存在运行时不兼容。

八、为什么 Node.js 18 会导致“静默失败”？

这是一个非常容易误判的点。

在本案例中，Node.js 18 的表现是：

🍄

可以正常安装依赖
🍄

可以拉起 MCP Server 进程
🍄

不会在 CLI 层报明显错误
🍄

但在 MCP initialize 阶段直接退出进程

这类问题的特点是：

🍄

不会提示“Node 版本过低”
🍄

不会提示“语法错误”
🍄

只在协议交互时暴露

因此，从使用者视角看，错误“看起来像 MCP 或 Chrome 的问题”。

九、最终解决方案（可复现步骤）

Step 1：确认当前 Node.js 版本

node -v

如果结果为 v18.x.x，请继续。

Step 2：切换或安装 Node.js 22

确保系统中可用的 Node.js 主版本为 22.x。

Step 3：使用 Node.js 22 重新安装 Codex / MCP

在 Node.js 22 环境下，执行完整安装流程，确保：

🍄

MCP Server 是在 Node.js 22 下构建和运行
🍄

.codex/mcp 目录为新生成状态

Step 4：重新启动 Agent Sandbox

此时：

🍄

chrome-devtools MCP 能正常启动
🍄

initialize 阶段不会再出现 connection closed

十、经验总结：这个问题为什么“隐蔽但必然发生”？

从工程角度看，这是一个典型的运行时漂移问题：

🍄

Codex / Sandbox / MCP 在持续演进
🍄

Node.js 18 虽然仍被广泛使用，但已处于“边缘兼容区”
🍄

新版本 MCP Server 对运行时特性的依赖提高
🍄

升级过程中未强制校验 Node 主版本

结果就是：

“

环境表面稳定，协议层面却已经不兼容。

十一、FAQ：开发者最常问的几个问题

Q1：为什么不在报错中直接提示 Node 版本问题？

因为 MCP Server 在 initialize 阶段失败前已经退出，客户端无法获得结构化错误信息。

Q2：Node.js 18 还能用于 Codex 吗？

在不启用 Agent Sandbox 或 chrome-devtools MCP 的场景下，可能“看起来可用”，但不建议继续使用。

Q3：是否需要修改 Chrome 或 MCP 配置？

在本案例中，不需要。
唯一变量是 Node.js 主版本。

Q4：问题是否会再次出现？

如果未来再次在较低 Node 主版本下更新 Codex / MCP，理论上会复现。因此建议在团队或个人环境中明确锁定 Node.js 主版本。

十二、结语：一次“看似是 MCP 的问题”，实则是运行时选择的问题

这个问题的价值，并不只在于“修好了”。

它更重要的意义在于提醒我们：

🍄

在多组件协作的 AI 工具链中
🍄

运行时本身就是一等公民
🍄

“之前能用”并不等于“现在仍然兼容”

通过这次排查，可以明确得出一个结论：

“

在 GPT-5.2-Codex + Agent Sandbox + chrome-devtools MCP 场景下，Node.js 22 是经过实证可用的稳定运行时选择。

这不是推测，而是一次完整问题闭环所给出的经验结论。

GPT-5.2-Codex中chrome-devtools MCP启动失败的终极修复：一个Node.js版本的陷阱