切换 Codex 账号后旧对话还在：本地会话存储的原理与备份迁移

换一个账号登录，本以为历史记录会跟着账号一起清空，结果打开客户端发现原来的对话、项目上下文一条没少，甚至可以直接接着聊。这种“意外之喜”其实不是某个版本的隐藏福利，而是这类命令行 AI 编程工具一贯的设计：对话属于你的磁盘，不属于你的账号。

搞清楚这一点很实用。它决定了你换号、续费、换机器、重装系统时该怎么操作才不会丢上下文，也解释了为什么有人在切换后会“历史全没了”——那通常不是账号的原因，而是路径、模式或环境变了。

结论先行：会话不在账号里，在本地

Codex、Claude Code 这类终端里跑的 AI 编程工具，工作方式是：客户端把每一轮对话、工具调用、文件改动记录写成本地文件；需要推理时，把相关上下文打包发给服务端；服务端只负责鉴权和生成，不负责托管你的历史。

所以换账号时发生的事只有一件：换了一把调用模型的钥匙。历史文件还在原地，客户端照常读取，自然一条不少。会话是按工作目录（也就是你启动客户端时所在的路径）归档的，同一目录下再次启动，客户端会把该目录对应的历史列出来供你继续。

会话存在哪儿、怎么组织

不同工具、不同版本的目录结构会有差异，但大体规律一致：都在用户主目录下的一个隐藏目录里，按项目路径或日期分文件夹，单条会话是一个 JSONL 文件。

• Codex 常见位置：主目录下的 .codex 目录（会话一般在其中的 sessions 之类子目录，按日期与会话 ID 命名）
• Claude Code 常见位置：主目录下的 .claude 目录，项目会话在 projects 下按路径生成的目录名里

先看一眼实际结构，比记结论更靠谱：

ls -la ~/.codex ~/.claude 2>/dev/null
du -sh ~/.codex ~/.claude 2>/dev/null
find ~/.codex -name '*.jsonl' | head

续接历史一般有两种入口：客户端启动时的会话选择器，或命令行参数（例如 Codex 的 codex resume、Claude Code 的 claude --continue / claude --resume）。具体子命令以你本地 --help 的输出为准。

三个容易误判的边界

网页端和命令行客户端是两套东西

网页版对话是账号绑定的，换号就是换了一整套历史；命令行客户端的历史是本地文件。别把两者的预期混在一起——在网页上找不到的旧对话，不代表终端里的也没了；反过来，终端里的历史也不会自动同步到网页。

切到 API Key 直连，历史可能不显示

有反馈称，把客户端从订阅登录切换为直接填 API Key 后，原来的会话列表就看不到了。这可能是客户端在不同鉴权模式下使用了不同的配置或会话路径，也可能是版本行为差异。稳妥的判断方法是：切换前后各执行一次 ls，对比目录有没有新增或变化。如果确实分开了，先备份再切，或者干脆用配置目录隔离的方式并行保留两套环境。

换机器、清缓存、容器重建，历史就真没了

本地存储的代价是：它不会跟着你走。以下操作会让上下文消失——重装系统、清理用户目录、在临时容器或 CI 环境里跑、用另一个系统用户登录、把项目挪到别的路径导致目录映射变了。如果你的工作依赖长期上下文，这些场景必须提前备份。

换账号时的操作清单

1. 先备份再动手。把整个配置目录复制一份（注意排除凭据文件），别只拷会话子目录，配置里可能还有模型、审批策略等偏好。
2. 在同一个工作目录下操作。换号后回到原项目路径再启动，历史才会被正确关联。
3. 确认登录状态生效。换号后先发一条最简单的请求，确认鉴权通过、额度正常，再继续正式工作。
4. 不要边跑任务边切号。正在执行的长任务中途换鉴权，容易得到失败的工具调用，留下半截会话。
5. 验证历史可读。打开一条旧会话，让它复述一下当前项目结构或最近改动，确认上下文确实被加载，而不是只显示了标题。

备份命令示例（先确认目录名再执行）：

mkdir -p ~/backup/codex
rsync -av --exclude 'auth.json' --exclude '*.log' ~/.codex/ ~/backup/codex/
# 需要归档时
tar -czf ~/backup/codex-$(date +%F).tar.gz -C ~ .codex

需要恢复时反向同步即可，但注意不要把旧凭据文件覆盖回新环境。

多账号、多项目怎么隔离

同一台机器上同时用多个账号或多个项目，最容易出的问题是历史串味：在 A 项目的目录里看到 B 项目的会话，或者不小心把敏感内容带进另一个账号的上下文。

• 按项目分目录：一个仓库一个顶层目录，不要在同一路径下混着做几个不相干的项目。
• 按环境分配置：多数客户端支持用环境变量指定配置目录，给不同账号各设一个，物理隔离最省心。
• 按需清理：临时试验性质的会话，用完删掉对应文件，避免几个月后自己都分不清哪条是有效上下文。
• 敏感信息：会话文件是纯文本，密钥、内网地址一旦被打进对话就落在磁盘上，共享机器或备份到云盘前要考虑这一点。

把历史接进自己的工具

既然会话是本地纯文本，就可以做二次利用：写脚本把多个客户端的历史解析成统一格式，导入自建的知识库或对话工具里继续追问。这在这类工具的用户群里已经是常见做法。

实施要点是：先摸清每种格式的字段结构，做好去重和脱敏，再考虑批量导入。同时提醒一句，解析客户端私有格式属于依赖实现细节的用法，升级后格式可能变化。把它当作“可选的便利”，不要当作长期稳定的数据资产方案；真正重要的结论应该沉淀到项目文档里，而不是只留在某条会话里。

订阅、支付与验证：没人能保证的部分

讨论里还夹杂了不少关于低价区订阅、跨境支付和手机号验证的内容，这部分需要泼点冷水。

关于异地低价订阅：不同地区的定价确实存在差异，但通过填写不实的账单地址、借助代付或共享方案去套低价，通常违反服务条款，后果包括订阅被撤销、账号被封、已付费用难以追回，出问题时也缺少正规渠道维权。税务信息同样不建议为了少付而伪造。合规的选择是按官方在你所在地区提供的方案订阅、使用官方团队或企业方案，或者对用量波动大的场景改用 API 按量计费——后者虽然单价看起来高，但没有“一个月跑爆额度”的焦虑。具体方案与价格请以官方最新说明为准。

关于验证码触发：什么时候会要求手机号或二次验证，属于平台风控策略，外部无法给出确定规则。能做的只是降低异常信号：不要频繁在短时间内切换账号，不要在多地区 IP 之间来回跳，保持登录设备和网络环境相对稳定，凭据不要多人共用。这些做法只能降低概率，不能保证不触发。

关于长时间在线：如果你需要让这类工具长时间挂着跑批量任务，本地机器休眠、断网、合盖都会打断会话，长任务重跑的成本很高。这种情况下，一种可选做法是把它放到一台长期在线的远程机器上——例如整台 Mac mini 托管在新加坡机房、按月远程使用的方案，网络环境相对稳定，也便于持续运行 Claude Code 这类工具。是否值得取决于你的任务时长和对稳定性的要求，本地机器能覆盖的场景没必要上远程。

小结

换账号后旧对话还在，不是运气，而是本地会话存储的必然结果。记住三件事就够了：历史跟着路径走，不跟着账号走；网页端和命令行端是两套历史；本地存储意味着必须自己负责备份。至于订阅价格和风控规则，那部分没有稳定的“技巧”可言，按官方渠道办事、把环境保持干净，比研究旁门左道更省时间。