1. Codex 计划模式 401 报错到底卡在哪一步Codex 计划模式Plan Mode是 Codex 在本地跑任务时的一种工作模式开启后它不会立刻改文件、执行命令而是先输出一份完整任务方案等你确认后再动手。这个模式本身不复杂真正让人头疼的是它跑不起来——终端里蹦出401 Unauthorized或者更绕的local proxy failed然后计划卡片一直转圈最后什么都没输出。我先把结论放前面这两个报错大概率不是 Codex 计划模式的逻辑坏了而是auth.json里的 endpoint 和鉴权字段没对上。Codex 在计划模式下会先做一次模型探测请求确认通道可用才生成计划这一步走的是auth.json里配置的地址和 Key只要其中一项错位计划模式就会在“还没开始规划”的阶段直接失败。适合读这篇的人用 Codex CLI 或 Codex 桌面端、通过auth.json配置模型通道、最近遇到 401 或 local proxy failed 的开发者。下面我会按“先定位、再改配置、再验证”的顺序走一遍每一步都给可复制的命令和字段你照着改就能确认到底是配置问题还是鉴权失效。先说清楚 401 和 local proxy failed 的区别这决定了你往哪个方向查401 Unauthorized是服务端明确告诉你“凭证不认”。常见原因有三个Key 写错或过期、auth.json里 endpoint 指向了一个不认这个 Key 的地址、请求头里的鉴权字段名不对比如该用Authorization: Bearer却写成了别的。local proxy failed是 Codex 本地代理层没起来或转发失败。它可能是端口被占、代理进程没启动、也可能是上游返回 401 后本地代理把错误包装成了这句。所以看到 local proxy failed 时别只盯着本地先看它上游是不是 401。计划模式之所以特别容易暴露这两个问题是因为它对通道的“首次探测”比普通对话更严格普通对话可能失败一次你重试就好计划模式在生成方案前会先确认模型可用探测失败就直接中断连计划卡片都不给你。所以排查思路是——先把通道打通再谈计划模式。2. TaoToken 前置把 Base URL 和 Key 准备好在改auth.json之前你得先有一个可用的通道地址和 Key。这里我用 TaoToken 作为示例通道因为它对 Codex 这类本地工具的接入比较直接Base URL 和 Key 的对应关系清晰排查起来不容易绕。你需要准备三样东西我把它叫“三件套”Base URLhttps://taotoken.net/api注意 API 地址不带任何查询参数直接就是这个API Key在控制台的 API Keys 页面创建形如sk-开头的一串字符Model ID你要调用的模型标识比如claude-sonnet-4-5这类具体以你账号下可用的模型为准创建 Key 的入口在这里https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite如果你还没决定用哪个模型可以先在模型对话页试一下确认 Key 和模型能通再写进auth.jsonhttps://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite这里有个容易踩的坑很多人把 Base URL 写成带/v1或带一堆参数的完整地址结果 Codex 在拼接请求路径时重复了最后打到不存在的端点上返回 401 或 404。TaoToken 的 API 根地址就是https://taotoken.net/apiCodex 会自己补后续路径你不要手动加。另外Key 的权限和额度也要确认。如果 Key 被禁用、额度耗尽服务端同样会返回 401 或 403。排查时先登录控制台看一眼 Key 的状态比在本地瞎改配置快得多。准备好这三件套后先别急着写auth.json用一条 curl 命令验证通道本身是通的。这一步能把“通道问题”和“Codex 配置问题”彻底分开curl -sS https://taotoken.net/api/v1/messages \ -H Authorization: Bearer sk-你的Key \ -H Content-Type: application/json \ -d { model: claude-sonnet-4-5, max_tokens: 64, messages: [{role: user, content: ping}] }如果这条命令返回了正常的 JSON哪怕内容只是模型回了个 pong说明 Base URL、Key、Model ID 三件套是对的问题在 Codex 的auth.json配置上。如果这条命令本身就 401那先解决 Key 或地址问题别往下走。3. 可复制配置auth.json 里 endpoint 与鉴权字段怎么改Codex 的auth.json一般放在用户配置目录下不同系统路径不一样macOS / Linux~/.codex/auth.jsonWindows%USERPROFILE%\.codex\auth.json改之前先备份一份出问题能回滚cp ~/.codex/auth.json ~/.codex/auth.json.bak下面是一份可复制的auth.json结构重点是base_url和api_key两个字段以及模型标识{ base_url: https://taotoken.net/api, api_key: sk-你的Key, model: claude-sonnet-4-5, provider: openai-compatible }几个字段的说明我按排查时最常出错的顺序讲base_url必须是https://taotoken.net/api不要带/v1不要带查询参数不要带结尾斜杠。带斜杠有时会导致拼接出//v1部分网关会因此返回 401 或 404。api_key直接填sk-开头的完整 Key不要加Bearer前缀。Codex 在发请求时会自己加Authorization: Bearer你手动加了就变成Bearer Bearer sk-xxx服务端当然不认直接 401。model填你在 TaoToken 控制台确认可用的模型 ID。填错模型名有的网关返回 404有的返回 401容易和鉴权问题混淆。provider字段如果你用的是兼容 OpenAI 协议的通道填openai-compatible如果你的 Codex 版本用的是别的字段名比如api_base或endpoint以你本地 Codex 文档为准但值都是同一个https://taotoken.net/api。如果你用的是 TOML 形式的配置部分 Codex 版本或周边工具用config.toml对应写法是[model_providers.taotoken] name TaoToken base_url https://taotoken.net/api api_key sk-你的Key model claude-sonnet-4-5改完保存然后重启 Codex。注意Codex 一般在启动时读取auth.json你改完不重启它还用旧配置会误以为没生效。如果你同时用 Cline、CC Switch 这类工具它们的配置里也要保持三件套一致Base URL 用https://taotoken.net/apiKey 用同一个Model ID 用同一个。三处不一致是 401 的高发原因——你在 A 工具里改了 KeyB 工具还用旧的报错就来了。4. 验证请求确认通道生效再开计划模式配置改完先别直接开计划模式跑大任务。用一条 curl 验证请求确认通道生效这一步能省掉大量来回。curl -sS -o /tmp/codex_check.json -w %{http_code}\n \ https://taotoken.net/api/v1/messages \ -H Authorization: Bearer sk-你的Key \ -H Content-Type: application/json \ -d { model: claude-sonnet-4-5, max_tokens: 32, messages: [{role: user, content: reply with ok}] }看输出如果第一行是200说明通道通了。再看/tmp/codex_check.json里的内容应该有正常的模型返回结构。如果返回401说明 Key 或地址还有问题返回404多半是模型名或路径不对。通道确认后回到 Codex 里开计划模式。开启方式两种对话输入框旁的开关或者输入/plan切换。开完先给一个简单需求比如“帮我梳理一下这个目录的结构先给方案别动手”看它能不能正常输出计划卡片。如果计划卡片正常出现说明 401 和 local proxy failed 都解决了。如果还报 local proxy failed检查本地代理端口是否被占lsof -i :你的代理端口把占用进程处理掉或者换一个端口。local proxy failed 有时是上一次 Codex 进程没退干净端口还占着新进程起不来。彻底退出 Codex 再重开往往就好了。实测下来大部分 401 都是api_key多写了Bearer前缀或者base_url带了/v1。这两个点先查能解决八成问题。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth这一节我把几个高频报错和对应原因列成对照你按现象查。401 UnauthorizedKey 错、Key 过期、Key 被禁用、base_url指向了不认这个 Key 的地址、api_key多写了Bearer前缀。逐个核对先用第 4 节的 curl 确认通道再查auth.json。local proxy failed本地代理没起来、端口被占、上游返回 401 被包装成这句。先看上游是不是 401再查端口占用最后彻底重启 Codex。reading choices相关报错通常是响应结构不符合 Codex 预期常见于base_url或model填错导致返回的不是标准结构。核对三件套确认模型 ID 在 TaoToken 控制台可用。OAuth相关报错如果你之前用 OAuth 方式登录过 Codexauth.json里可能残留 OAuth 字段和 API Key 字段冲突。把 OAuth 相关字段清掉只保留base_url、api_key、model三项重启 Codex。还有一个隐蔽的坑环境变量覆盖。有些 Codex 版本会优先读环境变量里的OPENAI_API_KEY或OPENAI_BASE_URL你改了auth.json但环境变量还指向旧地址结果还是 401。检查一下env | grep -i -E openai|codex|api_key|base_url有冲突的就 unset 掉或者改成和auth.json一致。排查顺序建议固定成先 curl 验通道 → 再查auth.json三件套 → 再查环境变量 → 最后查本地代理端口。按这个顺序走基本不会绕圈。6. 长期跑 Codex 计划模式的接入建议如果你只是偶尔用 Codex 计划模式上面改完就够了。但如果你打算长期用它跑重构、迁移这类大任务有几个接入上的建议。第一把三件套固定下来写进一个你随手能查的地方。Base URL 就是https://taotoken.net/apiKey 用控制台创建的Model ID 用你验证过可用的。三处Codex、Cline、CC Switch 等保持一致别一处一个样。第二计划模式适合复杂任务简单任务别开。单文件修改、小段调试直接执行模式更快。计划模式的价值在于先对齐思路再动手任务越大越值。第三Key 的额度要留意。计划模式在生成方案前会做探测请求长任务里请求次数不少额度耗尽会突然 401。定期在控制台看一眼用量。如果你要把 Codex 接进更长期的编码工作流或者跑 Agent 类任务可以了解一下 Coding Planhttps://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite接入文档在这里字段和路径以文档为准https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewrite最后说个我踩过的坑改完auth.json一定要重启 Codex而且要把旧进程彻底退干净。我有一次改了配置没重启折腾了半小时以为是 Key 的问题结果重启一下就好了。计划模式对配置的读取是启动时一次性的改完不重启等于没改。