1. Codex CLI 接入 DeepSeek 大模型为什么 auth.json 这条路值得走Codex CLI 是 OpenAI 推出的终端编程助手它通过 Responses API 与模型交互而 DeepSeek 的 API 原生兼容这一格式。这意味着你完全可以把 Codex 的请求指向 DeepSeek在终端里用国产大模型完成代码补全、重构、解释和 Agent 式任务。适合谁适合已经习惯命令行工作流、想用 DeepSeek 做日常编码、又不想被单一账号体系绑死的开发者。但很多人卡在第一步Codex 默认走 ChatGPT 账号登录登录界面要么跳浏览器、要么让你填 OpenAI API Key而你手里只有 DeepSeek 的 Key。这时候真正的入口不是登录框而是 Codex 的配置文件目录~/.codex/。其中auth.json负责认证方式config.toml负责模型提供方models.json负责模型元数据。三者配合才能让 Codex 把 DeepSeek 当成内置模型来用。我试过直接改config.toml却忘了auth.json里的认证方式结果 Codex 一直提示要登录 ChatGPT。后来才明白auth.json决定用哪种身份发请求config.toml决定请求发给谁。这篇教程就按这个顺序把auth.json改到 TaoToken 统一入口再配合config.toml和models.json给你一套可复制、可验证的完整流程。全程只需要一个 Key终端里跑一条命令就能确认接入是否生效。需要提前说明的是本文聚焦的是 Codex CLI 通过配置文件接入 DeepSeek 的流程不涉及任何账号注册教程的注水内容。每一步都有对应的文件路径、字段含义和验证命令你照着做就能复现。如果你之前被登录界面卡住过或者改完配置发现模型选择器还是空的那这篇就是为你写的。2. TaoToken 前置准备统一 Key 与 auth.json 的填写位置在动手改文件之前先把钥匙准备好。TaoToken 在这里扮演的是统一入口的角色你不需要在多个平台之间来回切换 Key而是用一个统一 Key 去调用包括 DeepSeek 在内的模型。对 Codex 来说它只关心三件事——Base URL、Key、Model ID。这三件套填对了接入就成功了一大半。先拿到你的 Key。打开 TaoToken 控制台进入 API Keys 页面创建一个新 Key。建议命名成codex-deepseek这种一眼能认出来的名字方便后续排查。创建后立刻复制保存因为页面刷新后完整 Key 通常不再显示。这个 Key 就是后面要填进auth.json和config.toml的核心凭证。接下来确认 Codex 的配置目录。Codex CLI、ChatGPT 桌面端、VS Code 的 Codex 插件共用同一份配置路径都在用户目录下的.codex文件夹里。macOS / Linux 是~/.codex/Windows 是C:\Users\你的用户名\.codex\。如果你从没运行过 Codex这个目录可能不存在先执行一次codex命令让它初始化或者手动创建目录。目录里通常有三个关键文件auth.json、config.toml、models.json。auth.json管认证config.toml管模型提供方models.json管模型元数据。很多人只改config.toml就以为完事了结果认证方式还是 ChatGPT 账号自然连不上。正确的做法是三个文件一起改顺序上先auth.json再config.toml最后models.json。关于 Base URLTaoToken 的 API 入口是https://taotoken.net/api。注意这里不要加任何多余的路径后缀Codex 会自己在后面拼接/responses等端点。Model ID 方面DeepSeek 系列常用的有deepseek-flash和deepseek-v4-pro前者支持图片输入后者推理能力更强。你可以根据任务类型在config.toml里切换默认模型。提示Key 只填一次但三个文件里出现的位置不同。auth.json里填在认证字段config.toml里填在experimental_bearer_token。两处必须一致否则会出现 401。如果你之前用过其他工具接入可能会习惯把 Key 放在环境变量里。Codex 也支持环境变量但本文为了可复制性统一采用写进配置文件的方式。这样无论你换终端还是换 IDE 插件读到的都是同一份配置不会出现CLI 能用、插件不能用的割裂情况。3. 可复制配置auth.json、config.toml、models.json 三件套这一节是全文的核心给你可以直接复制的 JSON 和 TOML 片段。路径与原文保持一致你只需要把 Key 和实际安装路径替换成自己的。先改auth.json它决定 Codex 用 API Key 认证而不是 ChatGPT 账号登录。auth.json的完整内容如下放在~/.codex/auth.json{ OPENAI_API_KEY: 你的 TaoToken 统一 Key, auth_method: apikey, preferred_auth_method: apikey, forced_login_method: api }这里OPENAI_API_KEY字段名是 Codex 沿用的历史命名填的其实是你的 TaoToken Key。auth_method和preferred_auth_method都设为apikeyforced_login_method设为api作用是跳过 ChatGPT 账号登录流程。如果你只改config.toml不改这里Codex 启动时仍会尝试走账号登录这就是很多人卡在登录界面的根本原因。接着改config.toml放在~/.codex/config.toml。注意这段内容要放在文件现有内容的前面否则模型提供方可能不生效model deepseek-flash model_provider taotoken preferred_auth_method apikey forced_login_method api model_reasoning_effort high web_search disabled model_catalog_json ~/.codex/models.json [model_providers.taotoken] name taotoken base_url https://taotoken.net/api wire_api responses experimental_bearer_token 你的 TaoToken 统一 Key几个关键点必须说清楚。model_provider的值taotoken要和下面[model_providers.taotoken]的段名完全一致大小写敏感。base_url填https://taotoken.net/api不要加尾部斜杠之外的路径。wire_api必须是responses因为 Codex 走的是 Responses API 协议。experimental_bearer_token填你的 Key注意把示例里的尖括号去掉只留 Key 本身。model_catalog_json指向models.json的路径。这里有个坑路径必须用正斜杠/即使在 Windows 上也要用~/.codex/models.json这种写法用反斜杠会直接报错。如果你把models.json放在别的位置就把这个路径改成实际位置。最后是models.json放在~/.codex/models.json。它向 Codex 声明 DeepSeek 模型的元数据包括上下文窗口、推理强度档位、工具调用格式等。内容较长核心结构如下{ models: [ { slug: deepseek-flash, display_name: DeepSeek-Flash, description: Latest frontier agentic coding model with image input., context_window: 1048576, max_context_window: 1048576, effective_context_window_percent: 95, default_reasoning_level: high, supported_reasoning_levels: [ { effort: low, description: Fast responses with lighter reasoning }, { effort: high, description: Extra high reasoning depth for complex problems }, { effort: max, description: Maximum reasoning depth for the hardest problems } ], input_modalities: [text, image], supports_parallel_tool_calls: true, supports_search_tool: true, visibility: list, supported_in_api: true, priority: 1 }, { slug: deepseek-v4-pro, display_name: DeepSeek-V4-Pro, description: Most capable frontier agentic coding model., context_window: 1048576, max_context_window: 1048576, effective_context_window_percent: 95, default_reasoning_level: high, supported_reasoning_levels: [ { effort: low, description: Fast responses with lighter reasoning }, { effort: high, description: Extra high reasoning depth for complex problems }, { effort: max, description: Maximum reasoning depth for the hardest problems } ], input_modalities: [text], supports_parallel_tool_calls: true, supports_search_tool: false, visibility: list, supported_in_api: true, priority: 2 } ] }deepseek-flash的input_modalities包含imageCodex 据此判断该模型可以接收图片。deepseek-v4-pro只支持文本但推理能力更强。两个模型的context_window都是 1048576effective_context_window_percent为 95意味着实际可用上下文约为窗口的 95%。supported_reasoning_levels定义了 low / high / max 三档推理强度对应config.toml里的model_reasoning_effort。三件套改完后保存所有文件。如果你担心中途出错可以先把原文件备份到~/.codex/backup/目录出问题随时还原。备份命令很简单mkdir -p ~/.codex/backup cp ~/.codex/auth.json ~/.codex/backup/auth.json.bak cp ~/.codex/config.toml ~/.codex/backup/config.toml.bak cp ~/.codex/models.json ~/.codex/backup/models.json.bak这样即使配置写错也能快速回到改之前的状态。接下来进入验证环节。4. 验证请求与成功结果一条命令确认接入生效配置写完不代表生效必须用实际请求验证。最直接的方式是进入一个项目目录执行codex命令观察启动信息里的模型标识。如果显示model: deepseek-flash说明 Codex 已经读取到你的配置并指向了 DeepSeek。cd /path/to/my-project codex启动后你会看到类似这样的输出Codex CLI v0.x.x model: deepseek-flash provider: taotoken reasoning effort: highmodel和provider两行是关键。model显示deepseek-flash或deepseek-v4-proprovider显示taotoken就说明config.toml和models.json都被正确读取了。如果provider还是openai或者model是空的说明配置没生效回到上一节检查字段名和路径。接下来做一次真实对话请求。在 Codex 交互界面里输入一个简单任务比如让它解释一段代码请解释下面这段 Python 代码的作用并指出潜在的性能问题 def find_duplicates(items): result [] for i in range(len(items)): for j in range(i 1, len(items)): if items[i] items[j] and items[i] not in result: result.append(items[i]) return result如果接入正常你会看到模型流式返回解释指出这是 O(n²) 的重复查找并建议用集合或字典优化。返回内容里不会出现请登录 ChatGPT或invalid api key之类的提示。这一步能跑通说明auth.json的认证方式、config.toml的 Base URL 和 Key、models.json的模型声明三者全部对齐。如果你想用命令行方式做一次非交互验证可以用管道把提示词传给 Codexecho 用一句话说明什么是快速排序 | codex预期返回是一段简短的中文解释比如快速排序是一种分治算法通过选取基准元素将数组分为两部分并递归排序。如果返回的是认证错误或空响应说明请求没有到达模型需要排查 Key 和 Base URL。对于 ChatGPT 桌面端和 VS Code 的 Codex 插件它们读取同一份配置。重启 ChatGPT 后模型选择器会显示自定义或DeepSeek-Flash。显示哪种取决于客户端版本但都算配置生效。VS Code 插件安装后直接使用无需单独配置。切换提供方后之前用 ChatGPT 账号产生的历史会话会暂时隐藏它们没有被删除只是按登录方式分组存放。恢复原配置后就能重新看到。注意验证时如果遇到local proxy failed或连接超时先检查base_url是否写成了https://taotoken.net/api不要多加/v1或/responses后缀Codex 会自己拼接。跑通这一步你的 Codex Agent 就已经在终端里用上 DeepSeek 了。接下来是排错环节把常见的坑一次说清。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth配置过程中最容易遇到四类报错每一个都有明确的成因和修法。先看 401这是最常见的一个。报错通常长这样Error: 401 Unauthorized {error:{message:Invalid API key provided,type:invalid_request_error}}成因有三个Key 填错、Key 两端带了尖括号、auth.json和config.toml里的 Key 不一致。修法是逐项核对。先确认auth.json的OPENAI_API_KEY和config.toml的experimental_bearer_token是同一个 Key且都没有尖括号。再确认 Key 没有多余空格。如果还报 401去 TaoToken 控制台确认这个 Key 是否被禁用或删除。第二类是local proxy failed报错类似Error: local proxy failed: dial tcp 127.0.0.1:xxxx: connect: connection refused这通常不是 Key 的问题而是 Codex 尝试走本地代理但代理没启动。检查你的终端环境变量里有没有HTTP_PROXY或HTTPS_PROXY指向一个不存在的本地端口。如果有临时取消这些环境变量再试unset HTTP_PROXY unset HTTPS_PROXY codex第三类是reading choices相关报错比如Error: failed to parse response: reading choices: unexpected end of JSON input这说明请求发出去了但返回的内容不是 Codex 期望的格式。常见原因是wire_api没设成responses或者base_url指向了一个不兼容 Responses API 的端点。确认config.toml里wire_api responsesbase_url https://taotoken.net/api。如果这两项都对检查models.json里的slug是否和config.toml里的model完全一致。第四类是 OAuth 相关报错比如启动时提示Error: OAuth token expired, please sign in again这说明 Codex 还在走账号登录流程auth.json没生效。检查auth.json是否存在、字段名是否正确、forced_login_method是否为api。如果文件存在但报错依旧可能是文件权限问题确保当前用户可读chmod 600 ~/.codex/auth.json下面用表格把四类报错和修法对照一下方便你快速定位报错关键词可能原因修法401 UnauthorizedKey 错误或带尖括号核对两处 Key 一致且无尖括号local proxy failed本地代理环境变量残留unset HTTP_PROXY / HTTPS_PROXYreading choiceswire_api 或 base_url 不对确认 responses 协议与 API 入口OAuth token expiredauth.json 未生效检查字段名与文件权限还有一个隐蔽的坑model_catalog_json路径用了反斜杠。在 Windows 上写~\.codex\models.json会直接报错必须写成~/.codex/models.json。另外config.toml里的配置段如果放在文件末尾而不是开头某些版本会忽略它建议放在最前面。如果你同时装了多个 Codex 客户端确认它们读的是同一个~/.codex/目录。有些 IDE 插件会用自己的配置目录这种情况下需要把三件套复制过去。排查时优先看启动日志里的provider和model两行它们能最快告诉你配置有没有被读到。6. 语义一致 CTA把 Key、文档和模型对话串起来配置跑通之后你手里其实已经有了三样东西一个统一 Key、一份可复制的配置文件、一条验证过的请求链路。接下来最值得做的是把这个链路固化下来让它成为你日常编码的默认工作流。如果你还没拿到 Key或者想再创建一个专门给 Codex 用的 Key可以直接去 API Keys 页面操作创建后按本文第 3 节的模板填进auth.json和config.toml即可。接入过程中如果对某个字段的含义拿不准比如wire_api为什么必须是responses、model_catalog_json到底声明了哪些元数据可以对照接入文档里的字段说明逐条核对。文档里对 Base URL、认证方式、模型目录的写法都有示例和你本文看到的配置能一一对应。遇到报错时先回第 5 节的对照表定位再去文档里确认字段拼写通常几分钟就能解决。想先确认模型本身是否可用不想动 Codex 配置可以打开模型对话页面用同一个 Key 发一条测试消息。如果那边能正常返回说明 Key 和入口没问题问题就缩小到 Codex 的配置文件上了。这种先验证 Key、再排查配置的顺序能帮你省下不少来回折腾的时间。如果你打算把 Codex 当成长期编码助手甚至跑 Agent 式任务那 Coding Plan 会更适合你。它面向持续性的编码场景配合本文的配置你可以在终端里稳定调用 DeepSeek 完成重构、补全、代码审查等任务。配置一次CLI、桌面端、IDE 插件三处通用不用重复折腾。最后留一个实用习惯每次改完配置文件先跑一遍codex看启动信息里的provider和model再用一句简单提示词做端到端验证。两步都通过再进入正式项目。这样即使某次改错了字段也能在第一时间发现而不是等到写代码写到一半才报错。