Codex MCP OAuth metadata discovery fails against n8n Cloud MCP server

这个报错通常出现在 Windows 上用 Codex 桌面客户端执行 codex mcp login n8n ,连接 n8n Cloud MCP Server 做 OAuth metadata discovery 时;Codex 还没打开浏览器授权窗口就报错。优先排查本机安全软件是否拦截/篡改 HT

快速结论:这个报错通常出现在 Windows 上用 Codex 桌面客户端执行 codex mcp login n8n,连接 n8n Cloud MCP Server 做 OAuth metadata discovery 时;Codex 还没打开浏览器授权窗口就报错。优先排查本机安全软件是否拦截/篡改 HTTPS 响应,其次排查 Codex 客户端版本。

适用环境:n8n Cloud,n8n version 2.40.7,Platform: Docker (Cloud),Node.js: 26.7.0,Database: SQLite,Execution mode: regular;Codex desktop client 26.917.71314;Operating system: Windows 10 x64。

最快修复方案:关闭杀软/安全软件的 HTTPS scanning(SSL inspection / Web Shield),然后重新运行 codex mcp login n8n;若无效,安装 codex-cli 0.155.0 再试。

注意事项:维护者已确认 n8n 侧的 OAuth metadata 端点返回正常 JSON,问题在 Codex 客户端一侧(尤其是 Windows 环境)。关闭 HTTPS 扫描会降低本地安全软件对加密流量的检查能力,请自行评估风险;降级 codex-cli 只是绕过 0.156.1 的 Windows 回归问题,并非长期方案。

问题场景

在 n8n Cloud 上为实例启用 MCP 并选择 Codex 后,把 MCP Server 地址写入 ~/.codex/config.toml,重启 Codex,再用 codex mcp list 确认服务已启用,最后执行 codex mcp login n8n。此时命令在 OAuth metadata discovery 阶段就失败,浏览器授权流程根本没有打开,整个过程不涉及 workflow execution。

MCP Server 本身在 codex mcp list 中显示为 enabled;MCP endpoint 返回 401,并通过 WWW-Authenticate header 指向 OAuth protected-resource metadata;直接请求 protected-resource metadata 和 authorization-server metadata 都能拿到有效 JSON。

报错原文

Metadata error: OAuth metadata discovery failed for https://<instance>.app.n8n.cloud/mcp-server/http
Caused by: HTTP request failed: error decoding response body

原因分析

Issue 维护者实测后确认:在一条正常的 n8n Cloud MCP Server 上执行 codex mcp login 可以成功,Codex 能发现 OAuth metadata、完成注册并打开浏览器;逐个检查 Codex 请求的 discovery URL,n8n 侧均返回合法 JSON。因此这不是 n8n Cloud MCP Server 端的问题,而是 Codex 客户端在 Windows 上的已知缺陷。

关键报错是 error decoding response body,即 Codex 拿到响应后无法解码。已知该问题在其他 MCP Server(如 Supabase、SharePoint)上同样会出现,可能原因包括:

  • 杀毒/安全软件的 HTTPS 扫描(SSL inspection / Web Shield)位于 Codex 与网络之间,篡改了响应内容,导致 Codex 读取失败。该原因在 openai/codex#48504 中被定位到 Avast。
  • codex-cli 0.156.1 的 Windows-only 回归问题,见 openai/codex#47756;0.155.0 可正常工作。

上述两条均来自 Codex 仓库的关联 Issue,属于“可能原因”,需要在本机逐项验证。

环境排查

  • 确认 Codex 客户端版本:Codex desktop client 26.917.71314(Issue 报告环境)。
  • 确认 n8n 侧:n8n Cloud、n8n version 2.40.7、Node.js 26.7.0、SQLite、regular 执行模式。
  • 确认操作系统:Windows 10 x64。
  • 确认本机是否安装并启用了带 HTTPS scanning / SSL inspection / Web Shield 的安全软件,Avast、AVG、Kaspersky、ESET、Bitdefender 通常默认开启该项。
  • 用 PowerShell 直接请求 discovery URL,检查响应是否为完整 JSON,用于区分 Codex 侧解码问题与网络中间人篡改。

解决步骤

  1. 先确认 Codex 侧配置正常:codex mcp list 中 n8n 显示为 enabled,且 ~/.codex/config.toml 中的 [mcp_servers.n8n] 的 url 指向 https://<instance>.app.n8n.cloud/mcp-server/http。
  2. 在 PowerShell 中执行以下命令,检查本机是否有人在中间拦截连接:
    curl.exe -v https://<your-instance>.app.n8n.cloud/.well-known/oauth-protected-resource/mcp-server/http
  3. 如果输出中出现 curl: (56) chunk hex-length char not a hex digit,说明连接被本机某进程拦截,可优先尝试在杀毒/安全软件中关闭 HTTPS scanning(可能叫 SSL inspection、Web Shield 或类似名称),然后重新运行 codex mcp login n8n。
  4. 如果 curl 输出是完整的 JSON 文档,说明网络链路干净,接着做第二步尝试:安装 codex-cli 0.155.0,再运行 codex mcp login n8n。
  5. 如果两步都无效,回到 Issue #39656 留言说明,维护者会再排查。

验证方法

重新执行 codex mcp login n8n,若 OAuth metadata discovery 不再报 error decoding response body,并正常打开浏览器授权窗口,说明问题已绕过或解决。也可以在 PowerShell 中再次运行上面的 curl.exe -v 命令,确认不再出现 chunk hex-length char not a hex digit,而是打印出完整的 JSON 文档。

参考来源

n8n-io/n8n #39656

openai/codex #48504

openai/codex #47756

GamsGo AI

AI 工具推荐

想把多个 AI 模型放在一个入口?

GamsGo AI 集成 ChatGPT、DeepSeek、Gemini、Claude、Midjourney、Veo 等常用模型,适合写作、绘图、视频和日常 AI 工作流。

了解 GamsGo AI

推广链接:通过此链接购买,我可能获得佣金,不影响你的价格。

这个方案解决了吗?

celebrityanime
celebrityanime
文章: 26103

发表回复

您的邮箱地址不会被公开。 必填项已用 * 标注