本帖使用社区开源推广，符合推广要求。我申明并遵循社区要求的以下内容：

• 我的帖子已经打上 开源推广 标签： 是


• 我的开源项目完整开源，无未开源部分： 是


• 我的开源项目已链接认可 LINUX DO 社区： 是


• 我帖子内的项目介绍，AI生成、润色内容部分已截图发出： 是


• 以上选择我承诺是永久有效的，接受社区和佬友监督： 是

以下为项目介绍正文内容，AI生成、润色内容已使用截图方式发出

这是什么

这是 Codex 线程撕裂者，专门用于撕裂线程之间的隔阂（中二病爆发）。解决在$CODEX_HOME/config.toml 里使用 model_provider 来切换不同 API 供应商后，却发现 Codex APP 里以前在别的 Provider 下的会话不见了，CLI 里的 codex resume 也找不到会话了的问题。

切 Provider 的方法如下：

model_provider = "test" # 在这里修改来切换



[model_provider.test]

name = "test"

wire_api = "responses"

base_url = "https://a.me/v1"

experimental_bearer_token = "sk-xxx"



[model_provider.test1]

name = "test1"

wire_api = "responses"

base_url = "https://a.me/v1"

experimental_bearer_token = "sk-xxx"

以下为 AI 写的 README 截图：

效果如何

使用前：

使用后：

可以看到，撕裂之后，所有的在各种不同 Provider 下的会话都能在 APP 里看到了。

如何安装

Homebrew

brew tap wangnov/tap

brew install codex-threadripper

npm

npm i -g codex-threadripper

cargo-binstall

cargo binstall codex-threadripper

cargo install

cargo install codex-threadripper

直接在 Release 里下载二进制

如何运行

这里就直接复制 README 了：

使用效果如下：

毫秒级解决！

咋做到的

简述一下这个项目的原理和设计，其实站内我也见过有其他佬友做的类似的项目，但和我的项目在设计上还是有一些区别。

大多数人可能对 Codex 的会话本体文件（$CODEX_HOME/sessions/$YEAR/$MONTH/$DAY/$SESSION_ID.jsonl）有所了解，比如搞注册机的时候都知道去里面伪造对话什么的（不是）。这个 jsonl ，也称之为 Thread，即本项目要撕裂的对象（bushi

jsonl里有一个字段：model_provider。就在第一行：

我这里显示的是 openai （小写），这个字段大小写敏感。而小写的 openai 是 Codex 的内置 Model Provider，APIKEY（应该没人用官 key 吧）和 ChatGPT 登录后，走的就是这个 Provider。它默认直打官方后端，且不能在 config.toml 里修改这个 Provider。

因此，中转使用，和官方登录使用，这两者之间的会话绝对是隔离开的。除非你 Patch 掉 Codex APP 和 CLI。

那么，很自然的我们就会想到，通过直接改 jsonl 里的 model_provider，统一为一个，不就可以实现解除隔离了吗？

是的，有的佬友的项目就是靠这个方式实现的。我一开始也是这样想的，但是实际上碰到了一个问题：

我的老天鹅，你知道 77 个 G 是什么概念吗，想修改这里面的所有 jsonl，跑一次就得好几分钟，体验极差。

不过幸好，可能 OpenAI 内部也有和我一样懒得删懒得清理又大量跑批处理的工程师吧，他们很自然的想到了一个办法：Sqlite 做索引。

得益于 Codex 出色的 APP-Server 架构，Codex APP 和 Codex CLI 都可以连接到一个统一的本地 app-server，而线程列表最终会落到一个 thread/list 接口上。这个接口直接去查 $CODEX_HOME/state_5.sqlite 里的 threads 表。

这个表里保存了每条线程的索引信息，比如：

id

rollout_path

created_at / updated_at

cwd

title

source

archived

model_provider

并且，Codex 不但把 model_provider 存在这里，还专门给它建了索引。

所以切 Provider 后会话看不到了的真实原因就不是因为在 jsonl 里的 model_provider 字段不同了，而是数据库层面的，实际上就可以简化为下面这个查询逻辑：

SELECT * FROM threads

WHERE archived = 0

  AND model_provider IN ('当前 provider')

ORDER BY updated_at DESC

所以 codex-threadripper 做的事情就很简单粗暴了。搞清楚之后，我们就顺势而为：：

1. 读取当前 $CODEX_HOME/config.toml 里的 model_provider


2. 如果没配置，就按 Codex 默认的 openai 处理


3. 先用 SQLite 官方 backup API 备份 state_5.sqlite


4. 然后把 threads.model_provider 统一改成当前 Provider


5. 后台 watch 模式继续监听配置变化和新增线程，自动继续撕裂线程（

核心逻辑约等于：

UPDATE threads

SET model_provider = '当前 provider'

WHERE model_provider <> '当前 provider';

这样做的好处就很显而易见，秒级改动，不用碰 77G 的 jsonl，不用逐个解析大文件，不用改会话正文。只改索引层，速度快，风险小。

而且 codex-threadripper 其实并没有把 jsonl 文件里的原始 model_provider 改掉。也就是说如果想真的去了解一下某个会话最初是从哪个 Provider 创建的，还是可以直接回源去看的。

说完了

以上就是这个小项目，希望对大家有帮助。有问题也欢迎直接丢 issue 进来。

后续还会有其他围绕 Codex 开发的项目分享，欢迎佬友插眼，我尽快写出来，也会作为合集更新到每个分帖子。

更新（2026-05-08）

版本 v0.2.1 已发布，请更新后使用

由于官方 Codex 更新 128 版本，里面加了一个重大的设计改动，我简述一下：

原本的切 provider 之后，我们看不到原本的 provider 的会话，本质上是对我们的一种保护（但是实际上对佬友大多数没用，后面我细说）。

而有好事者发现自己改 sqlite 里的 provider 就能实现跨 provider 恢复会话了（和我的逻辑一样），就兴冲冲的做了。结果做完发现：哎我咋会话恢复报错捏？

实际上这是因为，他用的是两个正规渠道：Azure 和 OpenAI ChatGPT订阅。

而这两个渠道，各自都有对自家的会话加密的逻辑。

这就导致了，我 Azure Provider 创建的会话，在 OpenAI 下就解不了会话的密文，导致报错。

因此此人上报 Issue，而 Codex 团队看到之后一拍脑子：干脆你们切 Provider 之后如果想恢复原本 Provider 的会话，就直接用原 Provider 继续好了。

我都懒得吐槽这个设计有多SB……

我切 Provider 的原因是啥？大多数情况下不是因为没钱了吗（），那你还给我切回去是何意味啊？而且对我们来说，无非是从一个 OpenAI 官方账号切到一个中转，只要中转不掺水用逆向的，也一样是 OpenAI 官方账号，不存在不能解的问题。

顺便，Codex 更新了根据 rollout 的 json 自动重建 sqlite 里的索引，把我这个工具的原本实现方法干掉了。现在我也只能原地改 rollout 里的第一行的 model_provider。只不过我用了原地 Patch ，先加 padding，后直接 patch，这样速度会快很多。

10s 内能解决 8000 条的检查和增量替换，这个速度还说得过去，虽然没有以前快乐了（

大家 Sessions 比我少的应该会快很多。

Codex 实用小工具系列目录

第一弹：【开源】切 provider 避免丢会话：Codex-Threadripper（Codex实用小工具系列第一弹）

第二弹：【开源】逆向 Codex APP ASR 搓了一个语音转写小工具，支持 Whisper 格式（Codex 实用小工具第二弹）

第三弹：【开源】做了一个 Codex App 安装包镜像，解决 Microsoft Store 不好下载的问题（Codex 实用小工具第三弹）