同步调用在 Qoder CN 里为什么必挂这件事一开始很容易看错方向。我在 WSL2 Ubuntu 里直接跑codex_run返回的是ROUTER_DIRECT_OK耗时 15 秒一次通过。可同样的调用放进 Qoder CN立刻就抛MCP_PROTOCOL_REQUEST_TIMEOUT。你可能会先怀疑是不是网络抖动、Key 失效或模型响应太慢但真正的原因是MCP 客户端等不了一个长时间才返回的 Tool Call。这篇排障记录就是围绕这个报错展开的。我会把 TaoToken 当作统一 API 通道先到 TaoToken 官网 拿一个 Key再把 Codex 的 Base URL 配成https://taotoken.net/api最后按异步链路把codex_start → codex_job_status → codex_job_result完整跑通。1. 报错现场WSL 直连正常Qoder CN 里同步调用超时1.1 同样的codex_run两种环境两种结果原文第十五节里我先把 Codex 做成了一个同步工具codex_run内部执行顺序是启动thread/start再触发turn/start然后一直等待 Codex 完成最后把结果返回给调用方。在 WSL 里单独验证这套逻辑输出是干净的ok: true status: completed durationMs: 15325也就是说Codex 本身没有坏任务也正常结束了总共用了 15 秒。但同样的逻辑被 Qoder CN 的 MCP 客户端调用时Qoder 那边直接报MCP_PROTOCOL_REQUEST_TIMEOUT我当时的第一反应也是查代理、查网络、查 ChatGPT Plus 登录态。可这些都没问题因为绕过 Qoder 直接调同一个 Router结果依然是completed。问题就出在「MCP 协议」对返回时间的容忍度上而不是 Codex 或网络。1.2 MCP 客户端不是为分钟级等待设计的MCP 协议里的 Tool Call 通常是同步语义客户端发起请求然后挂起等待响应。如果这个工具内部要跑一个完整的 Agent 任务而 Agent 可能要读代码、改文件、执行命令、等待模型多轮推理时间很容易从几秒拉长到几十秒甚至几分钟。大多数 IDE 集成层不会给单个 MCP 工具调用设置无限的等待时间超时之后就直接断掉连接然后抛出MCP_PROTOCOL_REQUEST_TIMEOUT。这个超时和「Codex 能不能跑完」是两回事。Codex 在后台其实还在继续工作只是 MCP 客户端已经不耐烦了。所以要解决的不是让 Codex 更快而是让 MCP 工具调用本身快速返回把真正的编码任务挪到后台执行再通过显式的查询接口获取进度和结果。2. 先用 TaoToken 把 Codex 接到标准 API 通道2.1 去 TaoToken 拿 Key替代 ChatGPT Plus 登录态原文里 Codex 是通过codex login --device-auth使用 ChatGPT Plus 登录态来认证的。这种方式依赖账号会话而且当你把 Codex 放进 Qoder CN 这类第三方客户端时登录态和网络环境会带来额外变量。这里我直接改用 TaoToken 提供的标准 API Key把认证方式统一成Authorization: Bearer YOUR_API_KEY不再依赖浏览器设备授权。操作很简单打开 TaoToken注册登录后在控制台创建一个 API Key复制下来备用。这个 Key 后面填进 Codex 的配置里不要贴到代码仓库或分享给别人。2.2 Codex CLI 的 Base URL 指向 TaoTokenCodex CLI 读取配置时可以通过~/.codex/config.toml自定义模型供应商。我新增了一个名为taotoken的 provider把 Base URL 指到https://taotoken.net/api注意末尾没有/v1也不要跟官网落地页混在一起model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key TAOTOKEN_API_KEYenv_key表示 Codex 会从环境变量TAOTOKEN_API_KEY里读取密钥。如果你不想每次启动都 export也可以直接在 Shell 配置里写export TAOTOKEN_API_KEYYOUR_API_KEY这样 Codex 发起的请求会统一走 TaoToken 的兼容通道TaoToken 再按你选的模型 ID 路由到对应的模型服务。模型 ID 不要凭记忆乱写打开 TaoToken 模型广场 看当前列表为准。3. 把codex_run改成异步 job 轮询绕过 MCP 超时3.1 同步转异步的最小改动原文第十六节已经给出了答案废弃同步codex_run改成四个独立工具codex_start、codex_job_status、codex_job_result、codex_cancel。核心流程变成codex_start启动一个后台 Codex 任务立即返回jobId。codex_job_status根据jobId查询任务状态比如starting、running、completed。codex_job_result任务完成后取回最终结果。codex_cancel如果任务卡死或不再需要主动终止。这样一个 MCP Tool Call 的耗时就从「等 Codex 跑完」降到了「几十毫秒返回 jobId」Qoder CN 的 MCP 客户端不会再碰到MCP_PROTOCOL_REQUEST_TIMEOUT。3.2 状态机要能区分正常工作和卡死异步化之后还有一个问题必须解决running状态不等于健康。原文中专门设计了health和lastActivityAt字段。我在实践里也是这样做的state: running health: healthy lastActivity: 3秒前说明 Codex 正在正常干活。如果health变成stale表示 worker 还活着但已经有一段时间没有新事件产生如果变成suspect说明需要警惕如果是dead那后台 worker 已经退出再去codex_job_result只会拿到一个失败结果。这套状态机看起来复杂但实际写起来并不难。你只需要在每个 Job 里保存startedAt、lastActivityAt、processAlive然后在codex_job_status里根据当前时间减去lastActivityAt算出secondsSinceLastActivity再用它判断健康度。Qoder 拿到状态后可以明确告诉你「Codex 还在跑」还是「可能卡住了」而不是永远转圈。4. 在 Qoder CN 里把异步链路真正跑通4.1 MCP Router 配置和异步工具调用顺序原文最终把 Router 做成了 MCP ServerQoder 通过标准 MCP 协议调用。配置里不需要再走 ChatGPT Plus 的设备登录而是把环境变量指到 TaoToken#!/usr/bin/env bash export OPENAI_BASE_URLhttps://taotoken.net/api export OPENAI_API_KEYYOUR_API_KEY exec $HOME/.local/bin/codex mcp-server如果用的是自定义 Router而不是官方codex mcp-server你只需要保证 Router 进程里能读到这两个环境变量。Qoder 那边的 MCP 配置继续用原来的方式启动wsl.exe Router 脚本不需要额外改网络层。异步调用顺序在 Skill 或 Rule 里写清楚即可。比如一个最简单的codex-workSkill 流程1. codex_models // 读取当前可用模型 2. codex_usage // 看还剩多少额度 3. codex_start // 传入 prompt 和 cwd启动后台任务 4. codex_job_status // 循环查询直到 completed 或 failed 5. codex_job_result // 获取最终改动结果这样一个循环里codex_job_status本身也是一个 MCP 调用但它的执行时间最多几十毫秒绝不会触发MCP_PROTOCOL_REQUEST_TIMEOUT。4.2 实测一次异步编码任务我按这个链路跑了一个真实任务让 Codex 修一个跨文件引用的 Bug。任务开始后Qoder 控制台显示的状态变化是starting → running → working → completed总耗时约 40 秒。这 40 秒里Qoder 和 Router 之间进行了多次codex_job_status轮询每次都是快速返回没有出现超时。最终codex_job_result返回了修改过的文件列表和 Diff 摘要。到这一步异步架构正式生效。之后你可以在 TaoToken 控制台 API Keys 页面看到这次调用的记录如果你想直接测试同一把 Key 是否在模型对话里可用可以打开 模型对话 发一条消息验证。若是长期写代码还可以看下 Coding Plan 里的套餐是否足够免得任务跑到一半额度不够。5. 还是超时的排障清单5.1 先检查 Base URL 是否写成了/v1这儿最容易踩坑把https://taotoken.net/api填成https://taotoken.net/api/v1或者把官网首页地址https://taotoken.net/?utm_sourcetaotoken_aicg_blog_end直接填进 Base URL。记住填进工具的接口地址是 https://taotoken.net/api不带/v1官网落地页只负责注册、创建 Key、看模型广场和用量。如果写错MCP 链接时能建立但一发起请求就会收到 404 或 401表现有时候也是超时。5.2 再确认模型 ID 是否真的存在Codex 调用模型时模型 ID 必须精确匹配 TaoToken 模型广场的列表。不要用旧文档里写死的名字因为模型列表会更新。正确做法是打开 TaoToken 模型广场把当前可用的模型 ID 复制到配置里。如果模型 ID 不存在TaoToken 会返回错误但 Qoder 那边可能因为 MCP 包装原因显示成MCP_PROTOCOL_REQUEST_TIMEOUT所以排障时要先看 Router 的日志。5.3 最后看是否真的走了异步链路如果你把配置全改对了但 Qoder 里依然超时那很可能是你的 Router 并没有真正把codex_run替换成codex_startcodex_job_statuscodex_job_result而是还在同步等待。检查一下codex_start是不是立即返回了jobId如果它一直等到任务完成后才返回那本质上还是同步MCP 超时依旧会发生。异步的核心不是“换名字”而是「启动动作」和「结果获取」彻底分离。这次排障到这里Codex 已经能在 Qoder CN 里稳定异步跑编码任务了。后续如果再遇到MCP_PROTOCOL_REQUEST_TIMEOUT不用再怀疑网络或额度先看你的 MCP 工具是不是在同步等一个 Agent 结束。把任务改成start → status → result轮询再配好 TaoToken 的 Base URL问题就自然消解了。