折腾了一下午，终于让 Codex 用上了 DeepSeek：一份 config.toml 配置与验证记录

1. 为什么我要把 Codex 接到 DeepSeek 上Codex 是 OpenAI 出的终端 AI 编程助手能在命令行里用自然语言描述需求、直接生成代码并落到文件里适合习惯在终端里写代码的人。DeepSeek 则是这两年性价比很高的模型代码生成和推理能力在线API 成本比主流闭源模型低不少。把这两个凑一起就是保留 Codex 的交互体验把背后的大脑换成 DeepSeek。听起来简单实际折腾了一下午。问题不在模型本身而在 Codex 的配置层它默认走 OpenAI 的端点模型名、baseURL、认证方式、流式响应解析这几处都得对上任何一处没改干净启动就会报错或者请求直接超时。我踩的坑主要集中在 config.toml 的字段写法和模型名映射上网上能搜到的片段要么太旧要么只改了环境变量没改配置文件跑起来还是走默认通道。这篇就把整个过程沉淀成可复现的步骤从 config.toml 骨架开始给出可复制的模型与通道配置片段再用一次对话请求验证接入是否生效。适合已经在用 Codex、想换后端模型的人也适合第一次接触 Codex 配置、想搞清楚每个字段作用的人。下面所有配置我都实测过命令可以直接抄。2. 前置准备TaoToken 通道与 Key 的获取Codex 要调 DeepSeek本质上需要一个兼容 OpenAI 协议的通道。我这边用的是 TaoToken 提供的统一接入通道它把模型调用收敛到一个 baseURL 和一把 Key 上配置层不用为每个模型单独改代码。官网入口在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 地址是 https://taotoken.net/api 注意 API 地址不带 UTM 参数配置里填这个就行。拿 Key 的路径是进控制台找到 API Keys 页面新建一把 Key。控制台地址 https://taotoken.net/console?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API Keys 页面 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。新建时给个能认出来的名字比如 codex-deepseek方便后面区分。Key 只在创建时完整显示一次复制下来存到本地密码管理器或者临时环境变量里别直接写进会提交到 git 的文件。这里有个容易忽略的点Codex 内部读的环境变量名是写死的通常还是 OPENAI_API_KEY 和 OPENAI_BASE_URL 这一套。也就是说你填的是 TaoToken 的 Key 和地址但变量名不用改Codex 认的就是这个名字。DeepSeek 和 TaoToken 通道都兼容 OpenAI 的认证格式所以 Key 直接填进去就能用。如果你之前配过别的通道先把旧的 OPENAI_BASE_URL 清掉避免残留值覆盖新配置。模型名这块DeepSeek 常用的有 deepseek-chat 和 deepseek-reasoner 两个前者偏通用对话和代码后者偏推理。Codex 场景我建议先用 deepseek-chat 跑通稳定后再按需切。模型名要和你通道里实际可用的名字一致写错了会直接返回 model not found。3. config.toml 骨架与可复制配置片段Codex 的配置分两层一层是 config.toml管模型、通道、超时这些结构化参数另一层是环境变量管 Key 这种敏感信息。我建议 Key 走环境变量其余走 config.toml这样配置文件可以进版本库Key 不会泄露。先看 config.toml 的骨架。文件一般放在用户目录下的 .codex/config.tomlWindows 是 %USERPROFILE%.codex\config.toml。如果目录不存在就手动建一个。下面是我实测能跑通的片段# ~/.codex/config.toml model deepseek-chat model_provider taotoken [model_providers.taotoken] name TaoToken base_url https://taotoken.net/api env_key OPENAI_API_KEY wire_api chat [model_providers.taotoken.query_params] # 部分通道需要显式声明留空即可 [profiles.deepseek] model deepseek-chat model_provider taotoken几个字段的作用说清楚。model 是默认模型名这里填 deepseek-chat。model_provider 指向下面定义的 provider 段。base_url 填 TaoToken 的 API 地址注意结尾不要多加 /v1具体以你通道文档为准我这边填 https://taotoken.net/api 能通。env_key 指定从哪个环境变量读 Key写 OPENAI_API_KEY 是为了兼容 Codex 内部逻辑。wire_api 用 chat对应 OpenAI 的 chat completions 协议。如果你更习惯用环境变量覆盖也可以不写 model_provider直接export OPENAI_BASE_URLhttps://taotoken.net/api export OPENAI_API_KEY你的TaoTokenKey export CODEX_MODELdeepseek-chat两种方式选一种就行别混着来。混用的时候容易出现 config.toml 里的 base_url 和环境变量里的 OPENAI_BASE_URL 打架最后走哪个取决于 Codex 的加载顺序排查起来很烦。我自己的做法是config.toml 管结构和默认值环境变量只放 Key模型名和地址都写在配置文件里。改完配置后用一条命令确认 Codex 读到了哪个文件codex config path输出会告诉你当前生效的配置文件路径。如果路径和你改的不是同一个说明你改错地方了这是最常见的「改了没生效」原因。4. 验证接入一次对话请求跑通全流程配置写完不代表通了得用一次真实请求验证。最直接的方式是让 Codex 跑一个简单任务看它是否返回代码、是否报错。先确认环境变量在当前 shell 里生效echo $OPENAI_API_KEY echo $OPENAI_BASE_URL两个都有值再往下。然后启动 Codex问一个最小可验证的问题codex 用 Python 写一个读取 CSV 并打印前 5 行的脚本如果接入正常Codex 会开始输出思考过程然后给出代码。我实测下来deepseek-chat 在这种小任务上响应很快基本秒回。返回的代码可以直接让它写入文件也可以复制走。想更纯粹地验证通道本身可以绕过 Codex直接用 curl 打一次 chat completionscurl https://taotoken.net/api/chat/completions \ -H Authorization: Bearer $OPENAI_API_KEY \ -H Content-Type: application/json \ -d { model: deepseek-chat, messages: [{role: user, content: 只回复两个字通了}], stream: false }返回 JSON 里 choices[0].message.content 是「通了」就说明 Key、地址、模型名三件套都对。这一步能快速把「通道问题」和「Codex 配置问题」分开curl 通但 Codex 不通问题在 Codex 配置curl 就不通问题在 Key 或通道。流式请求也建议测一次因为 Codex 默认走流式curl https://taotoken.net/api/chat/completions \ -H Authorization: Bearer $OPENAI_API_KEY \ -H Content-Type: application/json \ -d { model: deepseek-chat, messages: [{role: user, content: 数到三}], stream: true }能看到一行行 data: 开头的分片陆续返回就说明流式通道正常。Codex 对流的解析比非流式敏感这一步过了基本就不会再遇到「请求发出去了但界面卡住」的问题。5. 本篇常见报错与排查折腾过程中我遇到的报错集中在几类按出现频率排一下方便你对号入座。第一类是 401 Unauthorized。原因通常是 Key 没读到或者读错了。先 echo $OPENAI_API_KEY 确认有值再确认 config.toml 里 env_key 写的名字和实际环境变量名一致。如果 Key 是从控制台复制的注意别把首尾空格带进去。还有一种情况是 Key 被禁用或额度用尽去控制台 API Keys 页面看一眼状态。第二类是 404 model not found。模型名写错了或者通道里没有这个模型。deepseek-chat 和 deepseek-reasoner 是两个不同的名字别写成 deepseek 或者 deepseek-v3。用 curl 单独测一次模型名能快速定位。第三类是连接超时。DeepSeek 首次推理有时会慢一点尤其是长上下文。把 Codex 的 timeout 调大config.toml 里可以加request_timeout_ms 120000默认值偏小遇到复杂任务容易断。调到 120 秒基本够用。第四类是流式响应解析失败报错类似 unexpected end of JSON input。这多半是通道返回的分片格式和 Codex 期望的不完全一致。先确认 wire_api 写的是 chat再确认 base_url 结尾没有多余的斜杠或 /v1。如果还不行升级 Codex 到最新版新版本对非标准响应的容错更好。第五类是改了配置没生效。九成是改错了文件。用 codex config path 确认生效路径再检查有没有环境变量在覆盖配置文件。环境变量优先级通常高于配置文件旧的 export 没清掉就会一直走旧地址。排查顺序建议固定成curl 测通道 → echo 测环境变量 → codex config path 测配置文件 → 启动 Codex 测端到端。一层层往下别一上来就改代码。6. 跑通之后把配置沉淀下来跑通那一刻的体验还是不错的终端里还是熟悉的 Codex 交互背后换成了 DeepSeek简单任务几乎秒回复杂任务的代码质量也在线。成本这块同样的使用量比原来低不少具体数字因任务而异但体感差异明显。我的建议是把 config.toml 提交到自己的 dotfiles 仓库Key 走环境变量或者本地 .env 文件别进版本库。这样换机器的时候clone 下来配一下 Key 就能用。如果你后面想切模型改 config.toml 里的 model 字段就行通道和 Key 都不用动。长期在终端里做编码和 Agent 任务的话可以看看 Coding Plan 这类方案地址 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 适合把 Codex 这类工具当日常主力的人。想先验证模型对话效果模型对话入口在 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 字段含义和通道细节以文档为准。ClaudeCodeAnthropic 相关配置参考 https://taotoken.net/claudecode-anthropic?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。最后留一个我踩过的坑config.toml 里的 base_url 千万别手滑写成带 /v1 的完整路径不同通道对路径的处理不一样多一段少一段都会 404。填之前先用 curl 把地址测通再写进配置能省掉一半排查时间。