1. 为什么 Codex 桌面版直连 DeepSeek V4 会翻车Codex 桌面版接入 DeepSeek V4 这件事卡住大多数人的不是模型能力而是协议对不上。Codex 新版走的是 OpenAI 的 Responses API请求打到/v1/responses消息体用input字段而 DeepSeek V4 官方只提供 Chat Completions 兼容接口路径是/v1/chat/completions消息体用messages数组。你把 Codex 的base_url直接改成https://api.deepseek.com/v1它发出去的还是 Responses 格式的请求对面只认 Chat Completions轻则返回 400重则在多轮工具调用时静默断链。我试过最直接的改法把wire_api设成chat想让 Codex 退回旧协议。结果新版 Codex 已经不再支持这个值配置直接报错。所以正确的思路不是改 Codex也不是等 DeepSeek 支持新协议而是在本机跑一个轻量桥接服务把 Responses API 的请求翻译成 Chat Completions再把返回结果翻译回去。这篇就交付一套可复制的config.toml骨架、桥接服务启动命令以及一次端到端验证动作确认 Codex 桌面版能稳定调用 DeepSeek V4。适合谁看已经在用 Codex CLI 或 Codex 桌面版、想换成 DeepSeek V4 省成本、又不想改客户端源码的开发者。你需要会基本的终端操作能编辑 TOML 和.env文件剩下的照抄即可。2. 前置准备TaoToken 与 DeepSeek V4 的接入底座在动手写桥接之前先把上游的调用凭证和模型入口理清楚。桥接服务本身不产生模型能力它只是个翻译层真正干活的是上游的 DeepSeek V4。如果你希望统一管理多个模型的 Key、或者想用一套凭证同时对接 Codex 和其他编码工具可以走 TaoToken 的接入方式官网在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite API 入口是 https://taotoken.net/api 。它的作用是给你一个兼容 OpenAI 格式的调用地址和 Key桥接服务把上游指向它即可不用在多个平台之间来回切换凭证。不管用哪家上游桥接服务需要三个东西一个可用的 API Key、一个 Chat Completions 兼容的 base_url、一份要暴露给 Codex 的模型列表。DeepSeek V4 当前的模型标识建议用deepseek-v4-pro和deepseek-v4-flash旧的deepseek-chat、deepseek-reasoner会逐步下线新配置别再写它们。环境上确认两件事Node.js 版本不低于 18因为桥接脚本用了--env-file参数Codex CLI 能正常跑codex --version。桌面版和 CLI 共用同一份~/.codex/config.toml所以先在 CLI 上把链路调通桌面版自然就通了。node --version # 需要 v18.0.0 或更高 codex --version # 确认 Codex CLI 已安装3. 可复制配置桥接服务与 config.toml 骨架3.1 部署桥接服务在用户目录下建工作区把桥接脚本放进去。这里以单文件 Node 脚本为例核心职责是监听本地端口、接收/v1/responses请求、转换成/v1/chat/completions转发、再把 SSE 流式事件映射回 Responses 格式。mkdir -p ~/.codex/codex-bridge cd ~/.codex/codex-bridge # 将桥接脚本 proxy.mjs 放入此目录桥接脚本要处理四类转换路径映射/v1/responses→/v1/chat/completions、消息体转换input→messages、工具调用闭环function_callitem ↔tool_calls、流式事件重写response.output_text.delta↔choices[0].delta.content。工具调用这块是质量分水岭简单问答看不出差别一旦 Codex 要读文件、跑命令转换不完整就会中途卡死。3.2 配置环境变量在~/.codex/codex-bridge/.env写入上游凭证和监听参数# 上游配置 DEEPSEEK_API_KEYsk-你的密钥 DEEPSEEK_API_BASEhttps://api.deepseek.com # 若走 TaoToken改为 https://taotoken.net/api # 暴露给 Codex 的模型列表 DEEPSEEK_MODELSdeepseek-v4-pro,deepseek-v4-flash # 默认供应商 DEFAULT_PROVIDERdeepseek # 本地监听 PROXY_HOST127.0.0.1 PROXY_PORT4000 # 日志 LOG_LEVELinfoPROXY_HOST必须是127.0.0.1不要写0.0.0.0否则同局域网的其他设备也能访问你的桥接服务等于把 Key 暴露出去。.env文件记得加进.gitignore别提交到公开仓库。3.3 配置 Codex 的 config.toml编辑~/.codex/config.tomlWindows 下路径是C:\Users\你的用户名\.codex\config.tomlmodel deepseek-v4-pro model_provider deepseek_bridge cli_auth_credentials_store file [model_providers.deepseek_bridge] name DeepSeek V4 Local Bridge base_url http://127.0.0.1:4000/v1 wire_api responses request_max_retries 4 stream_max_retries 5 stream_idle_timeout_ms 600000最关键的一行是wire_api responses。它告诉 Codex 用 Responses API 格式和模型通信而这正是桥接服务期望接收的格式。base_url指向本地 4000 端口不是 DeepSeek 官方地址。stream_idle_timeout_ms给到 600000是因为 DeepSeek V4 在长上下文推理时首 token 可能来得慢超时设太短会误判断流。3.4 用 Profile 管理多模型切换Codex 支持 Profile 机制可以在 Pro 和 Flash 之间快速切换不用每次改配置# 默认使用 Pro model deepseek-v4-pro model_provider deepseek_bridge cli_auth_credentials_store file [model_providers.deepseek_bridge] name DeepSeek V4 Local Bridge base_url http://127.0.0.1:4000/v1 wire_api responses request_max_retries 4 stream_max_retries 5 stream_idle_timeout_ms 600000 # 快速模式轻量任务用 Flash [profiles.fast] model_provider deepseek_bridge model deepseek-v4-flash # 推理模式复杂任务用 Pro [profiles.deep] model_provider deepseek_bridge model deepseek-v4-pro切换时用codex --profile fast或codex --profile deep不带参数就用默认配置。4. 启动与端到端验证4.1 启动桥接服务cd ~/.codex/codex-bridge node --env-file.env proxy.mjs启动成功后终端会打印监听地址和模型列表Listening on http://127.0.0.1:4000 Default provider: deepseek Models: deepseek-v4-pro, deepseek-v4-flash这个终端窗口要保持开着关掉桥接服务就停了Codex 会连不上上游。4.2 分层排查验证不要一上来就跑 Codex按上游到本地的顺序逐层验证出问题好定位。第一步验证上游 API 直连curl https://api.deepseek.com/v1/chat/completions \ -H Content-Type: application/json \ -H Authorization: Bearer sk-你的密钥 \ -d { model: deepseek-v4-pro, messages: [{role: user, content: 回复ok}], stream: false }返回正常说明 Key 有效、余额充足、网络通。失败先查 Key 和账户余额。第二步验证桥接服务的模型列表curl http://127.0.0.1:4000/v1/models应返回包含deepseek-v4-pro和deepseek-v4-flash的 JSON 数组。没有返回就检查.env里的DEEPSEEK_MODELS改完要重启桥接服务。第三步验证桥接服务的 Responses 转换curl http://127.0.0.1:4000/v1/responses \ -H Content-Type: application/json \ -d { model: deepseek-v4-pro, input: 只回复一个字好 }返回好说明 Responses → Chat Completions 的转换链路已打通。第四步验证 Codex CLI 完整链路codex exec 只回复一个字好输出好说明 Codex CLI → 本地桥接 → DeepSeek API 全链路正常。再跑一个真实编码场景确认工具调用没问题codex exec 写一个 Python 函数接收字符串列表返回按长度排序后的新列表。4.3 在 Codex 桌面版中使用确认桥接服务运行中再启动 Codex Desktop。在对话窗口切换模型/model deepseek-v4-pro或/model deepseek-v4-flash模型选择建议复杂代码分析、项目级重构、长上下文调整用deepseek-v4-pro快速问答、轻量修改、短代码补全、高频交互用deepseek-v4-flash。桌面版和 CLI 共用配置CLI 通了桌面版基本不会有额外问题。5. 本篇常见错排查5.1 切换模型时找不到 DeepSeek 模型先验证桥接服务的模型端点curl http://127.0.0.1:4000/v1/models无返回就检查.env里的DEEPSEEK_MODELS拼写改完必须重启桥接服务配置不会热加载。5.2 端口 4000 被占用Windowsnetstat -ano | findstr :4000 taskkill /PID PID /FmacOS / Linuxlsof -i :4000 kill -9 PID或者换端口同步改.env的PROXY_PORT和config.toml的base_url两处必须一致。5.3 桥接服务启动失败常见原因三个Node.js 版本低于 18--env-file参数不识别.env格式错误多个配置挤在一行或加了多余引号依赖缺失检查项目是否需要先npm install。5.4 DeepSeek API 返回 402账户余额不足。DeepSeek API 需要账户有余额才能调用登录控制台充值后重试。5.5 Codex 桌面版提示登录窗口先检查 CLI 登录状态codex login status需要初始化 API Key 登录时codex login --with-api-key如果桌面版仍要求登录确认cli_auth_credentials_store file写在配置文件的顶层不是某个 section 里面。5.6 工具调用中途断链这是桥接质量问题的典型表现普通聊天正常但 Codex 读文件、跑命令时卡住。根因是function_call_output回传链路没转换完整。排查时看桥接服务日志确认tools定义、tool_calls字段、role: tool消息、流式事件类型是否都被正确映射。选桥接方案时优先看它 README 里有没有明确声明对 tools、tool_calls、tool result、stream events 的完整支持。6. 长期编码与 Agent 场景的接入建议如果你只是偶尔用 Codex 跑几个任务本地桥接 按量付费的 DeepSeek V4 就够了。但如果你把 Codex 当日常编码主力频繁跑 Agent 任务、批量重构、长上下文分析按量计费的波动会比较明显这时候可以考虑 Coding Plan 这类包月方案把成本固定下来。接入入口在 https://taotoken.net/api Key 的创建和管理在 https://taotoken.net/api-keys 配置文档在 https://taotoken.net/doc 。桥接服务的.env里把DEEPSEEK_API_BASE指向对应地址即可Codex 侧配置不用动。想先验证模型对话效果、确认 Responses 转换是否正常可以用模型对话页面快速试一条请求地址是 https://taotoken.net/model-chat 。如果你用的是 Claude Code 而不是 Codex接入路径不同参考 https://taotoken.net/claude-code-anthropic 的说明。最后提醒一句桥接服务更新后建议重新跑一遍第 4 节的四步验证尤其是工具调用功能。协议转换层是最容易在版本升级时出问题的地方链路验证比事后排查省事得多。
