GPT 5.5 的 MCP 调用翻车了？只需这一招临时救急

最近在折腾 AI 编程助手的小伙伴可能碰到了一件怪事：明明之前跑得好好的 MCP（Model Context Protocol），一升级到最新版的 Codex（无论是 App 还是 CLI），哪怕配置没动，只要接入特定的 GPT 5.5 模型，就会立刻“变傻”——要么列表加载转圈卡死，要么直接显示没检测到任何 MCP 服务器。

折腾了半天，排查了半天网络和配额，最后发现这锅还真不全是用户的。今天就给大家复盘一下这个问题的成因，以及那个“简单粗暴”但管用的临时解决方案。

问题现象：升级之后必卡死？

根据最近的反馈，问题主要集中在使用较新版本的 Codex 客户端（例如 0.142.2 或 0.120.0 以上版本）时。当你试图调用 MCP 列出 Resources（资源）或 Templates（模板）时，请求不仅超时，甚至会拖垮整个会话进程，让 Codex 陷入“装傻”状态，假装你的 MCP 服务器不存在。

Telegraph (any的破事让any自己解决) gpt 5.5的mcp调用失败临时办法，禁用search_tool就行 继续【破案了就是any问题】为什么codex0.1

如果你也是这种情况，别急着重装系统，大概率是遇上了一个兼容性新坑。

根本原因：supports_search_tool 的兼容性冲突

经过深入分析日志和测试，终于找到了元凶：这个问题的核心在于某些服务商提供的 GPT 5.5 接口，目前尚未完全兼容新版 Codex 引入的 supports_search_tool 特性。

简单来说，新版 Codex 在初始化 MCP 连接时，会默认声明支持搜索工具（supports_search_tool）。如果后端的 GPT 5.5 模型对这个声明理解有误，或者干脆不支持该特性的握手协议，就会导致交互逻辑卡死。结果就是，Codex 在等待一个永远不会到来的正确响应，最终表现为无法识别 MCP 服务器。

临时解决方案：禁用 Search Tool

既然是模型端还没“准备好”，那我们只能在客户端这边做点“降级”处理了。目前的临时解决办法非常直接：强制禁用 Codex 的 search_tool 功能。

这样做相当于告诉后端模型：“我不需要那个高级的搜索功能，咱们就按最基础的模式通信。” 这样就能绕过那个卡死流程，让 MCP 连接恢复正常。

操作思路（具体视你的客户端配置而定）：

在 Codex 的配置文件或启动参数中，找到与 MCP 或搜索工具相关的设置项，将 supports_search_tool 或类似的选项设置为 false，或者直接移除相关声明。

例如，在某些配置场景下，你需要确保 MCP 服务的初始化参数中不包含对搜索能力的请求。一旦屏蔽了这个特性，你再尝试 mcp list，应该就能秒出结果了。

写在最后

虽然是“any 的问题”（某些服务商接口兼容性没跟上），但咱们作为用户，还得靠这种 workaround 来保生产力。期待后续模型更新能正式补齐这块短板，到时候咱们再把这功能放开用。如果你刚好也遇到这个卡顿bug，不妨试试这招，大概率能“药到病除”。