1. Codex CLI 会话状态丢失到底丢在哪从 auth.json 与 Base URL 说起Codex CLI 的 conversation history lost 和 Session state not saved表面看是「历史没了」实际多数时候是会话文件根本没写成功或者写到了另一个目录、另一个账号体系下。我先把结论放前面Codex CLI 的会话持久化依赖两件事——本地~/.codex/sessions/目录能正常写入以及auth.json里的认证信息与 Base URL 指向同一个可用的服务端点。只要这两者有一处对不上codex --continue就会报No previous conversation found或No session to continue。先解释 Codex CLI 是什么、能做什么、适合谁。Codex CLI 是 OpenAI 推出的终端编程助手可以在命令行里直接对话、读写代码、执行多轮任务。它适合习惯在终端里工作的开发者尤其是需要把 AI 编码能力嵌进脚本、CI 流程或本地项目的人。它的会话机制是「按工作目录 会话 ID」组织的每次对话会落盘成一个 JSON 文件--continue默认只找当前目录最近的那条会话。那为什么改auth.json和 Base URL 能影响会话状态因为 Codex CLI 在启动时会先读auth.json完成鉴权再根据配置里的 Base URL 建立请求通道。如果鉴权失败或 Base URL 不可达请求会在写入会话文件之前就中断于是你看到的现象就是「对话能开但历史不保存」。更隐蔽的一种情况是你换了 Base URL 但没同步更新auth.json里的 keyCLI 用旧凭证去请求新端点返回 401会话写入被跳过--continue自然找不到东西。我实测下来会话丢失的诱因里文件被系统清理约占三成工作目录不匹配约占两成半剩下的大头就是认证与端点配置不一致。前两类靠ls ~/.codex/sessions/和回到原目录就能排查后一类必须动auth.json和 Base URL。所以这篇排查记录的重点是把配置改对再用三步动作验证改动是否真的生效。需要先明确一个边界本文讲的是把 Codex CLI 的请求端点配置到 TaoToken 的 API 地址属于正常的接口配置操作。TaoToken 提供的是模型调用通道官网在 https://taotoken.net/?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content API 地址是 https://taotoken.net/api 。配置时只填这两处不要引入任何网络代理类工具也不需要。下面按「先定位、再配置、后验证」的顺序展开。每一步都给可复制的命令和字段你照着做就能复现问题、改配置、确认历史恢复。2. 前置准备拿到 TaoToken 的 Key 并确认 Codex CLI 版本在改auth.json之前先把两样东西准备好一个可用的 API Key以及确认你本机 Codex CLI 的版本和配置文件位置。这一步不做后面改了也可能因为版本差异导致字段名对不上。先看版本。不同版本的 Codex CLI 对auth.json字段的命名略有差异老版本用api_key新版本更常见的是OPENAI_API_KEY或嵌套在tokens下。先跑一条命令确认codex --version如果输出类似codex-cli 0.x.x记下主版本号。接着确认配置文件目录。Codex CLI 默认把配置放在~/.codex/下里面通常有auth.json、config.json或config.toml以及sessions/子目录。用下面这条命令一次性看清楚ls -la ~/.codex/正常应该能看到auth.json和sessions。如果sessions不存在先建出来否则会话无处落盘mkdir -p ~/.codex/sessions然后是拿 Key。打开 TaoToken 的控制台进入 API Keys 页面创建一个新 Key。地址是 https://taotoken.net/api-keys?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。创建后复制那串以sk-开头的字符串先存到临时变量里别直接贴进聊天窗口export TAOTOKEN_KEYsk-你的实际key这里提醒一句Key 只显示一次复制后妥善保存。如果你之前已经在用别的端点建议新建一个 Key 专用于 Codex CLI方便后续排查时区分是 Key 的问题还是配置的问题。再确认一下模型 ID。Codex CLI 需要知道调用哪个模型常见的是gpt-5、gpt-5-codex这类。你可以在 TaoToken 的模型对话页面先试一次确认这个模型在你的账号下可用。模型对话入口在 https://taotoken.net/chat?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 。在网页里发一条消息能正常返回说明 Key 和模型都没问题再往 CLI 里配。前置准备做完你手里应该有三样东西Codex CLI 版本号、~/.codex/目录结构、一个可用的sk-Key。接下来进入配置环节。3. 可复制配置auth.json 字段与 Base URL 填写位置这一节是核心。Codex CLI 的会话状态能不能持久化取决于auth.json和 Base URL 是否配对。我把两份配置都写出来你直接复制改 Key 即可。先备份原配置避免改坏cp ~/.codex/auth.json ~/.codex/auth.json.bak 2/dev/null || true然后写auth.json。下面这份是通用结构字段名以你实际版本为准如果版本较新OPENAI_API_KEY是主字段如果版本较老可能同时需要api_key。两份都写上不会冲突{ OPENAI_API_KEY: sk-你的实际key, api_key: sk-你的实际key, base_url: https://taotoken.net/api, tokens: { access_token: sk-你的实际key } }写入命令cat ~/.codex/auth.json EOF { OPENAI_API_KEY: sk-你的实际key, api_key: sk-你的实际key, base_url: https://taotoken.net/api, tokens: { access_token: sk-你的实际key } } EOF注意base_url这一行值必须是https://taotoken.net/api结尾不要多加斜杠也不要写成/v1之外的路径。Codex CLI 会在这个地址后面拼接具体的请求路径多写斜杠会导致 404进而让会话写入失败。接着配config.json部分版本是config.toml。这份配置负责模型 ID 和会话存储行为。JSON 版本{ model: gpt-5-codex, provider: openai, baseURL: https://taotoken.net/api, sessionDir: ~/.codex/sessions, saveSession: true, maxSessions: 50 }写入cat ~/.codex/config.json EOF { model: gpt-5-codex, provider: openai, baseURL: https://taotoken.net/api, sessionDir: ~/.codex/sessions, saveSession: true, maxSessions: 50 } EOF如果你的版本用 TOML等价写法是model gpt-5-codex provider openai base_url https://taotoken.net/api session_dir ~/.codex/sessions save_session true max_sessions 50这里三件套必须齐全Base URL 填https://taotoken.net/apiKey 填sk-开头那串Model ID 填你在网页端验证过可用的那个。缺任何一件Codex CLI 要么鉴权失败要么请求发不出去会话文件就不会生成。配完检查一下 JSON 语法避免手抖多逗号python3 -m json.tool ~/.codex/auth.json python3 -m json.tool ~/.codex/config.json两条都输出格式化后的 JSON 且没有报错说明语法没问题。如果报Expecting property name之类回去检查逗号和引号。还有一个容易忽略的点sessionDir如果写成相对路径Codex CLI 会按当前工作目录解析导致你在 A 目录的会话存到了 A 下换到 B 目录就找不到了。所以这里统一用绝对路径~/.codex/sessions或者展开成/home/你的用户名/.codex/sessions。配置写完后先别急着开新会话下一节用三步动作验证改动是否真的生效。4. 验证请求重启会话、复现丢失、确认历史恢复配置改完不等于生效必须走一遍验证。我把它拆成三步重启会话、复现丢失、确认历史恢复。三步都过才算真正修好。第一步重启会话。先确保没有残留的 Codex 进程占用旧配置pkill -f codex 2/dev/null || true然后在一个测试目录里启动mkdir -p ~/codex-test cd ~/codex-test codex进入交互界面后发一条带标记的消息比如「记住这个标记SESSION-TEST-001回复收到」。等它回复后正常退出/exit第二步复现丢失。这一步是故意制造「看起来丢了」的场景确认你的配置能扛住。先看会话文件有没有落盘ls -la ~/.codex/sessions/如果配置生效这里应该出现一个新的 JSON 文件文件名带时间戳或会话 ID。如果目录是空的说明saveSession没生效或sessionDir路径不对回到第 3 节检查。接着用--continue恢复cd ~/codex-test codex --continue如果之前报No previous conversation found现在应该能直接进入上次的上下文。你可以问它「刚才的标记是什么」它应该答出SESSION-TEST-001。这一步过了说明会话持久化链路是通的。第三步确认历史恢复的稳定性。再开一条新消息然后退出再--continue一次确认多次恢复不丢codex --continue在会话里发「再记一个标记SESSION-TEST-002」退出再codex --continue问它两个标记应该都能答出来。如果第二次恢复失败多半是maxSessions太小或磁盘写入有问题检查df -h ~磁盘满了会导致写入静默失败这是会话丢失里占比不低的一类原因。另外验证一下跨目录行为。--continue默认只找当前目录的会话这是设计如此不是 bug。如果你在~/codex-test建的会话跑到别的目录--continue找不到属于正常。要恢复指定会话用--resumecodex --resume --list codex --resume session-id--list会列出所有会话 ID挑一个--resume进去。这样即使换了目录也能精确恢复。三步走完你应该能稳定复现「发消息 → 退出 → 恢复 → 历史还在」的闭环。如果某一步失败对照下一节的报错排查。5. 本篇常见错排查401、local proxy failed、reading choices、OAuth配置过程中最常见的几类报错我按现象、原因、处理列出来你对照自己的终端输出定位。第一类401 Unauthorized。现象是启动后发消息直接报鉴权失败会话文件不生成。原因通常是auth.json里的 Key 和 Base URL 不匹配或者 Key 已失效。处理确认auth.json里OPENAI_API_KEY和base_url同时存在且 Key 是sk-开头去控制台重新生成一个 Key 替换。检查命令python3 -m json.tool ~/.codex/auth.json | grep -E OPENAI_API_KEY|base_url如果 Key 显示为sk-你的实际key这种占位符说明你忘了替换回去改。第二类local proxy failed。现象是请求发不出去提示本地代理失败。这类报错往往和系统里残留的代理环境变量有关。先清掉unset HTTP_PROXY HTTPS_PROXY http_proxy https_proxy ALL_PROXY all_proxy然后确认没有额外的代理配置干扰。Codex CLI 直连https://taotoken.net/api即可不需要任何中间层。清完环境变量重开终端再试。第三类reading choices 相关报错。现象是返回体解析失败提示读取 choices 字段出错。这通常是 Base URL 拼错导致返回了非预期内容。确认base_url是https://taotoken.net/api没有多余路径。可以用 curl 直接验证端点curl -s https://taotoken.net/api/models \ -H Authorization: Bearer $TAOTOKEN_KEY | head -c 300能返回模型列表 JSON说明端点和 Key 都对。返回 404 或 HTML说明地址写错了。第四类OAuth 相关报错。现象是提示 OAuth 登录或 token 刷新失败。Codex CLI 某些版本会尝试走 OAuth 流程如果你用的是 API Key 模式需要在配置里显式声明不要走 OAuth。检查config.json里provider是否为openai并确认没有残留的 OAuth token 文件ls ~/.codex/ | grep -i oauth如果有先移走再重试。API Key 模式下不需要 OAuth 凭证。第五类会话文件损坏。现象是--continue报Session file is corrupted。处理是验证 JSON 并删除坏文件find ~/.codex/sessions/ -name *.json -exec python3 -m json.tool {} \; 21 | grep -B1 Error定位到坏文件后删掉重新开新会话。坏文件多半是上次写入时进程被强杀导致的养成正常/exit退出的习惯能减少这类问题。第六类多终端冲突。现象是两个终端同时--continue同一会话后写入的覆盖前面的。处理原则是不要多终端恢复同一会话需要并行就在不同目录开不同会话。排查时记住一个顺序先看ls ~/.codex/sessions/有没有文件再看auth.json的 Key 和 Base URL最后看网络和磁盘。大部分会话丢失都能在这三步里定位。6. 把配置固化下来长期稳定使用 Codex CLI 的建议排查完一次最好把配置固化避免下次升级或换机器又踩一遍。我的做法是把关键配置写进一个初始化脚本换环境时跑一遍即可。脚本内容大致如下放在~/setup-codex.sh#!/usr/bin/env bash set -e mkdir -p ~/.codex/sessions cat ~/.codex/auth.json EOF { OPENAI_API_KEY: sk-你的实际key, api_key: sk-你的实际key, base_url: https://taotoken.net/api, tokens: { access_token: sk-你的实际key } } EOF cat ~/.codex/config.json EOF { model: gpt-5-codex, provider: openai, baseURL: https://taotoken.net/api, sessionDir: ~/.codex/sessions, saveSession: true, maxSessions: 50 } EOF python3 -m json.tool ~/.codex/auth.json /dev/null python3 -m json.tool ~/.codex/config.json /dev/null echo codex config ready每次换机器或重装后跑一次省去手动改字段的麻烦。注意脚本里的 Key 要替换成你自己的别把带真实 Key 的脚本提交到仓库。另一个习惯是退出前把关键结论写进文件。会话文件虽然能--continue但它不如普通文件可靠——系统清理、版本升级都可能让它失效。在会话里直接让它落盘codex 把当前讨论的结论整理成 docs/session-summary.md这样即使会话丢了成果还在。文件比会话更持久这是我踩过几次坑之后最实在的经验。如果你需要长期跑编码任务或 Agent 类工作流可以考虑用 Coding Plan入口在 https://taotoken.net/coding-plan?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 配合 Codex CLI 的会话持久化能把多轮任务的上下文稳定保留下来。接入文档在 https://taotoken.net/doc?utm_sourcetaotoken_aicg_blog_endutm_mediumcsdnutm_campaignrewriteutm_content 字段有疑问时对照文档核对。最后再强调一次三件套Base URL 填https://taotoken.net/apiKey 填sk-开头那串Model ID 填你验证过可用的那个。三者一致Codex CLI 的会话状态就能稳定落盘--continue和--resume都能正常工作。配置改完按第 4 节的三步动作走一遍确认历史真的恢复再投入日常使用。