1. 先搞清楚 codex resume 找不到 Session 的真实原因如果你正在用 Codex CLI并且最近把 Provider 从官方账号换成了第三方兼容接口然后发现codex resume里空空如也先别急着删目录重装。我试过历史会话文件其实一个都没丢它们只是被 Codex 的召回逻辑“藏”起来了。Codex 的历史会话默认存在本地每个会话对应一个 Session 文件里面除了对话内容还有一段元数据最关键的就是provider字段。Codex 在列出可恢复会话时会拿当前config.toml里的 provider 去和每个 Session 文件里的 provider 做匹配只有两边一致这条会话才会出现在codex resume的列表里。换句话说Session 文件存在不等于它一定可见真正决定可见性的是“当前 Provider Session Provider”这个等式。这就解释了一个很常见的现象你之前用官方登录Session 里记的是provider openai后来你切到自建或第三方兼容接口config.toml里写的是provider my-provider。Codex 扫描时发现当前是my-provider而历史会话是openai不匹配于是直接过滤掉。表现出来就是“历史记录消失”实际上文件还在原地。这个场景特别容易发生在几类迁移里官方账号切到兼容 OpenAI API 的服务、中转站 A 切到中转站 B、Azure 切到 OpenRouter、或者你自己给 Provider 改了名字。只要 provider 标识变了历史召回就会断。下面我会先讲清楚 config.toml 里 provider 和 session 存储路径的关联再给一份可复制的配置骨架最后用实际命令验证历史能不能回来。2. TaoToken 前置准备Base URL、Key 与 Model ID 三件套在动手改配置之前先把接入侧的三件套准备好这样后面改config.toml时不会来回翻文档。无论你用的是哪家兼容 OpenAI 的服务Codex 侧需要的信息都是固定的三项Base URL、API Key、Model ID。以 TaoToken 为例API 地址是https://taotoken.net/api注意这个地址不带任何查询参数直接作为 base_url 使用。API Key 在控制台的 API Keys 页面生成路径是https://taotoken.net/console/api-keys?utm_sourcetaotoken_aicg_blog_endutm_contentapi-keysutm_campaignrewrite。生成之后先复制到本地安全的地方后面写进config.toml或者环境变量都行。Model ID 则取决于你要调用的模型比如gpt-5、claude-sonnet-4-5这类具体以模型对话页面展示的为准页面地址是https://taotoken.net/models?utm_sourcetaotoken_aicg_blog_endutm_contentmodel-chatutm_campaignrewrite。这里有个容易踩的坑很多人把 base_url 写成带/v1的完整路径结果 Codex 内部又拼了一次/v1导致 404。TaoToken 的 API 根地址就是https://taotoken.net/apiCodex 会按自己的规则补全路径你不需要手动加/v1。如果你用的是其他兼容服务也先确认它的根地址格式再决定要不要带版本号。另外Provider 的命名建议保持稳定。一旦你给某个接入点起了my-provider这个名字后续就不要再改成my-provider-2或别的否则每次改名都会触发一次历史召回断裂。命名稳定是避免这个问题复发的最简单办法。如果你需要长期做编码和 Agent 任务可以考虑用 Coding Plan 来统一管理接入配置入口在https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_contentcoding-planutm_campaignrewrite这样 Provider 标识不容易被随手改乱。准备好这三项之后就可以进入配置环节了。下面给的骨架是 TOML 格式路径和字段名都按 Codex 的实际读取习惯来写你可以直接复制后替换成自己的值。3. 可复制的 config.toml 骨架与 Session 路径关联Codex 的配置文件默认在~/.codex/config.tomlSession 文件默认在~/.codex/sessions/目录下。这两个路径是关联的核心config.toml决定当前 Provider 是谁sessions/里的每个文件记录它属于哪个 Provider。下面是一份可复制的骨架你可以按自己的接入信息替换。# ~/.codex/config.toml model gpt-5 model_provider my-provider [model_providers.my-provider] name my-provider base_url https://taotoken.net/api env_key TAOTOKEN_API_KEY wire_api chat这段配置里model_provider my-provider就是当前 Provider 标识它必须和 Session 文件里的provider字段一致历史才会显示。base_url填 TaoToken 的 API 根地址env_key指向你存放 Key 的环境变量名wire_api按服务支持的协议填兼容 OpenAI Chat Completions 的用chat。Key 不要直接写进 TOML用环境变量更安全export TAOTOKEN_API_KEY你的Key如果你用的是 Codex 的 auth.json 方式也可以把凭证放在~/.codex/auth.json但要注意 auth.json 和 config.toml 的 Provider 标识要对应上否则会出现 OAuth 或 401 类报错。Session 文件的结构大致是这样{ provider: my-provider, model: gpt-5, messages: [] }当你执行codex resume时Codex 读取config.toml里的model_provider然后扫描~/.codex/sessions/下所有文件只把provider字段等于my-provider的会话列出来。所以修复思路只有两条要么把config.toml的 provider 改成和历史一致要么把历史 Session 里的 provider 批量改成和当前一致。对于官方账号迁移过来的情况第一条路往往走不通因为 Codex 不允许你把自定义 Provider 命名为openai会把它识别为官方 Provider 而拒绝。这时候只能走第二条路批量替换 Session 文件里的 provider 字段。手工改几十上百个文件不现实可以用脚本处理cd ~/.codex/sessions grep -rl provider: openai . | while read f; do sed -i s/provider: openai/provider: my-provider/g $f done执行前先备份整个 sessions 目录确认替换范围无误再跑。替换完成后当前 Provider 和历史 Provider 重新匹配codex resume就能看到旧会话了。4. 验证请求用 codex resume 确认历史会话回来了配置改完下一步是验证。先确认环境变量已经生效再启动 Codex 看历史列表。第一步检查 Key 是否被正确读取echo $TAOTOKEN_API_KEY如果输出为空说明环境变量没导出成功回到上一步重新 export。接着确认 config.toml 里的 provider 标识grep model_provider ~/.codex/config.toml输出应该是model_provider my-provider和你 Session 文件里的 provider 一致。然后执行codex resume如果历史会话回来了你会看到之前那些对话标题重新出现在列表里选中任意一条能正常加载上下文。这时候再发一条新消息确认请求能正常打到 TaoToken 的接口codex 用一句话说明当前 provider 是什么返回内容正常说明 Base URL、Key、Model ID 三件套都通了。如果返回 401检查 Key 是否过期或复制时带了空格如果返回 404检查 base_url 是否多写了/v1如果报local proxy failed通常是本地网络或代理配置干扰先确认没有额外的代理层在拦截请求。验证通过后建议把当前可用的 config.toml 备份一份命名成config.toml.bak下次再换 Provider 时可以直接对照。另外如果你同时用多个接入点可以在 config.toml 里定义多个[model_providers.xxx]段通过切换model_provider的值来换但每次切换后都要确认历史 Session 的 provider 是否匹配否则又会遇到“历史消失”的假象。对于需要长期跑编码任务的场景可以用 Coding Plan 把接入配置固定下来减少手动改 provider 的频率。模型对话页面也可以用来单独验证某个 Model ID 是否可用避免在 Codex 里反复试错。5. 本篇常见错排查401、local proxy failed 与 reading choices实际排查中报错信息往往比“历史消失”更直接。下面按真实遇到的报错逐条对照。401 Unauthorized最常见的原因是 Key 没被读到。先echo $TAOTOKEN_API_KEY确认环境变量存在再检查 config.toml 里的env_key是否和 export 的变量名完全一致大小写敏感。如果用的是 auth.json检查里面的凭证字段是否和当前 provider 对应。还有一种情况是 Key 本身失效去控制台重新生成一个再试。local proxy failed这个报错通常和本地网络环境有关比如系统级代理、公司网络策略、或者某个本地转发工具在拦截。先确认没有额外的代理层在跑再检查 base_url 是否可达curl -I https://taotoken.net/api。如果 curl 能通但 Codex 报这个错检查 Codex 自身有没有配置 proxy 相关字段把它清掉再试。reading choices 相关报错这类错误一般出现在响应解析阶段说明请求发出去了但返回结构不符合预期。常见原因是wire_api填错比如服务实际是 Responses 协议但你填了chat或者反过来。对照服务文档确认协议类型改完重启 Codex。另外 Model ID 写错也可能导致返回体里没有 choices 字段检查 model 值是否和模型对话页面展示的一致。OAuth 报错如果你之前用官方登录auth.json 里可能残留 OAuth 凭证切到自定义 Provider 后这些凭证不再适用。解决办法是清掉旧的 auth.json 或把里面的 provider 相关字段更新成当前值。注意不要同时保留两套冲突的凭证否则 Codex 可能随机选一套导致行为不稳定。历史仍然不显示如果配置都对了但codex resume还是空用grep -r provider ~/.codex/sessions/ | head抽查几个 Session 文件确认 provider 字段真的被替换成了当前值。有时候替换脚本因为引号格式不同没匹配上比如文件里是单引号或没有空格需要调整 sed 表达式。替换前务必备份替换后抽查确认。排查顺序建议是先看环境变量再看 config.toml再看 Session 文件最后看网络。大部分问题集中在前两步真正需要动网络配置的情况很少。6. 把 Provider 标识固定下来历史就不会再丢整件事的核心就一句话Codex 的历史召回靠的是当前 Provider 和 Session Provider 的匹配。你换 Provider 时只要保证两边标识一致历史就一直可见。官方账号迁移到自定义 Provider 之所以麻烦是因为openai这个标识不能被自定义 Provider 复用只能反过来批量改 Session 文件。实操上我建议把 Provider 命名当成一个长期约定一旦定下就不要随意改。config.toml 里用model_provider指向它Session 文件里记录它两边对齐。需要换接入点时优先改 base_url 和 Key而不是改 Provider 名字这样历史召回不会断。如果确实要改名字就用脚本批量替换 Session 里的 provider 字段替换前备份替换后抽查。接入侧的三件套保持稳定也很重要Base URL 用https://taotoken.net/apiKey 放环境变量Model ID 按实际调用的模型填。需要验证模型可用性时去模型对话页面单独测需要长期跑编码任务时用 Coding Plan 固定配置。把这些固定下来codex resume找不到 Session 的问题基本不会再出现。