CodeX windows app使用第三方api以及session记录还原

适宜背景

之前使用openai订阅然后需要切换到中转站或者自定义api的人

从中转换到另外一个中转发现掉历史记录的人。

历史记录有备份，导入后不知道怎么还原的人。

第一节 codex如何使用第三方api

无论是codex cli还是codex app都是共用一份配置文件的。

配置文件在类似于C:\Users\22586\.codex的位置，中间22586是你的个人文件夹

直接修改的例子：

model_provider = "codex" model = "deepseek/deepseek-v4-flash" model_reasoning_effort = "high" disable_response_storage = true #我建议设置为false [model_providers.codex] name = "codex" base_url = "https://open.cherryin.ai/v1" wire_api = "responses" requires_openai_auth = true

配置细节和额外配置

拓展上下文的参数：

model_context_window = 1000000 model_auto_compact_token_limit = 900000

model_provider = "codex"
作用：指定使用哪个模型供应商配置块
关联：它对应下方 [model_providers.codex] 段落，告诉 Codex CLI “去这个配置块里找 API 地址、认证方式等信息”
如果你有多个供应商（如 [model_providers.openai]、[model_providers.azure]），这里决定用哪一个
model = "deepseek/deepseek-v4-flash"
作用：每次 API 请求时发送的模型名称
传递方式：它会被原样放入请求体的 model 字段中发给 base_url
你当前情况：你用的是 DeepSeek 的模型（v4-flash 是 DeepSeek 的轻量快速版），通过第三方代理 cherryin 中转调用
注意：这个值是否有效取决于你的 base_url 后端是否认识 deepseek/deepseek-v4-flash 这个名字
model_reasoning_effort = "high"
作用：控制推理模型（如 o 系列、gpt-5 系列等）的内部推理深度
可选值：
"none" → 不做额外推理，直接输出
"low" → 轻度推理
"medium" → 中等推理（默认）
"high" → 深度推理
影响：
设成 "high" 会让模型在内部多“思考”几轮，质量更高但 token 消耗翻倍甚至更多
对于不支持推理参数的非推理模型（如 gpt-4o、deepseek-v4-flash），这个参数可能被忽略
适用条件：你的 API 后端需要支持 OpenAI 的 reasoning_effort 参数
disable_response_storage = true
作用：禁止 Codex CLI 将对话内容保存到本地磁盘
设为 true 时：
会话不会被写入 ~/.codex/conversations/ 目录
关闭终端后历史对话彻底消失，无法用 /resume 恢复
设为 false 或省略时（默认）：
对话自动存档，可随时恢复
适用场景：处理敏感代码/密钥、临时一次性任务、不想留痕
🔧 [model_providers.codex] 配置块
name = "codex"
作用：这个供应商配置的标识名称
显示位置：
/status 命令中显示的 provider 名称
日志/错误信息中出现
可以随便起名，比如 "deepseek"、"my-proxy" 等，但必须和全局 model_provider 的值一致
base_url = "https://open.cherryin.ai/v1"
作用：所有 API 请求的最终目的地
工作方式：
Codex CLI 会把请求发到 https://open.cherryin.ai/v1/responses（因为 wire_api = "responses"）
这是一个第三方代理服务器，不是 OpenAI 官方
影响：

你需要在 cherryin 平台上单独购买额度
DeepSeek 官方 API 地址应该是 https://api.deepseek.com/v1，而 cherryin 是一个中转服务
wire_api = "responses"
作用：决定使用 OpenAI 的哪套 API 协议来发送请求
可选值：
"responses" → 使用 OpenAI 最新的 Responses API（统一了对话 + 工具调用 + 结构化输出）
"chat/completions" → 使用传统的 Chat Completions API
关键区别：
"responses" 是 OpenAI 2025 年后推出的新接口，功能更强（原生支持多轮工具调用、状态管理等）
"chat/completions" 是经典接口，兼容性最好，几乎所有第三方代理都支持
你的情况：cherryin 代理支持 "responses" ，如果 后端实际只支持 Chat Completions 格式，请求会直接报错
requires_openai_auth = true
作用：控制 HTTP 请求的认证头格式
设为 true 时：
Codex CLI 在请求中加上 Authorization: Bearer <你的API密钥>
这是 OpenAI 的标准认证方式
设为 false 时：
可能用其他认证方式（如 x-api-key 头），取决于代理服务器的要求

个人建议

如果你是新手没有聊天记录或者不在乎聊天记录，或者短时间内不会切换api，直接使用ccswitch即可。

但是如果你有这种切换的需求，建议设置好。

大部分中转站都有直接导入到cc switch的快捷方式。

切换到api登录之后，我使用了cc switch单纯用于在多个不同的toml中切换，所以我建议的流程是。

手动配置好配置文件，准备换中转的时候再用ccswitch新建配置，然后同样的配置好，注意provider最好设置为相同的值。这样cc switch主要是作为一个切换工具而不是管理具体配置内容的工具。

第二节 切换api出现的问题

聊天记录消失

原因排查：cc switch历史对话是否可以看见

如果你的会话都在，但是codexapp不显示，那么恭喜你，在这里大概率可以解决。

Codex 不是单纯把会话文件按时间列出来，而是先按 model_provider 的值作为内部桶（bucket）来过滤。你在 config.toml 里把 model_provider 从openai改成 中转api再改成 其他的，相当于换了三个桶，旧桶里的历史在界面上自然就“消失”了——文件其实还在 ~/.codex/sessions 里，只是没被加载。

换言之，model_provider 不仅是配置块的名字，更是历史记录的分桶 key；name 只是显示名，换它不会影响历史归属。

临时解决方案：

codex cli的话直接执行cc switch给的这个命令就可以暂时先回到对应的对话中了。

codex配置出现沙盒无法设置问题

这是由于你配置文件内provider的设置有问题。

有两种可能：

1，你设置了provider，但是没有设置对应的配置块，或者像下面一样，配置错误，codex无法从下面找到codex，下面只有codex1.

model_provider = "codex" model = "deepseek/deepseek-v4-flash" model_reasoning_effort = "high" disable_response_storage = true #我建议设置为false [model_providers.codex1] name = "codex" base_url = "https://open.cherryin.ai/v1" wire_api = "responses" requires_openai_auth = true

2，你设置了不可覆写的provider，比如openai。这是openai的自留配置。

model_provider = "openai" model = "deepseek/deepseek-v4-flash" model_reasoning_effort = "high" disable_response_storage = true #我建议设置为false [model_providers.openai] name = "codex" base_url = "https://open.cherryin.ai/v1" wire_api = "responses" requires_openai_auth = true

修改方式很简单，第一个是设置正确的配置块，第二个是修改provider为其他字符串。

原理解释

Codex 对话记录的管理方式决定了什么是“丢历史”

Codex 把每场会话保存在 ~/.codex/sessions 和 ~/.codex/archived_sessions 下，同时维护一个 sqlite 状态库 (state_*.sqlite)。在展示历史列表时，它会先用 model_provider 的值作为筛选条件，只加载属于当前 provider 的对话。

也就是说，model_provider 在这里充当的是桶（bucket）的角色——你换一个 provider，就等于换了一个桶，之前桶里的对话文件虽然还在磁盘上，但界面上就看不见了。config.toml 里的 name 字段只是给你看的标签，并不参与历史记录的归属判断。

因此，只要保持 model_provider 不变，无论你怎么改 name、base_url、api_key，历史记录都不会丢失。如果你已经因为更换 provider 而“丢了”对话，可以用专门的迁移脚本把分散在不同桶里的记录统一到同一个 provider key 下，脚本会同步修正会话文件和数据库，重启 Codex 后它们就会重新出现。

解决脚本和示例配置

大佬的解决方案：寻求codex对话session记录不丢失方案，在官号和API key之间切换。 - 开发调优 - LINUX DO

我这里写了一个脚本更直接一点，脚本其实就是做了一件事，把历史记录的provider全部统一迁移到当前provider。不管历史记录是什么，全部都切换到当前的配置。

注意执行所有命令之前都建议备份你的.codex文件夹。

请查看：

https://blog.csdn.net/m0_54138660/article/details/160767760?fromshare=blogdetail&sharetype=blogdetail&sharerId=160767760&sharerefer=PC&sharesource=m0_54138660&sharefrom=from_link