Codex++：它不是让 Codex 变聪明，而是把 Codex App 的缝补上
最近看 BigPizzaV3/CodexPlusPlus，我第一反应不是“Codex 又多了一个增强工具”，而是 Codex App 的生态开始变味了。
它表面上做的是中转、插件解锁、会话删除、Markdown 导出、Zed、worktree、自动更新这些功能。但如果只把它当成一个功能集合看，就会漏掉更关键的东西。
Codex++ 真正值得看的地方，不是它又给 Codex App 加了几个按钮，而是它说明了一件事：Codex App 已经开始从一个官方客户端，变成一个需要外围工具链来补缝的桌面工作台。
过去我们聊 AI Coding 工具，注意力基本都在模型上。谁更会改代码，谁上下文更长，谁工具调用更稳，谁更适合大型重构。但用久了会发现，很多真正影响日常体验的问题，其实不在模型那一层。
比如你已经登录了官方 ChatGPT，但又想把模型请求切到自己的兼容 API；API Key 模式下，插件入口突然不好用了；会话列表只有归档，没有真正顺手的删除；一段长会话想导出 Markdown，还得自己翻本地存储；远程 SSH 项目想从 Codex 直接打开编辑器，路径映射又不一定对。
这些都不是“大功能”。但它们堆在一起，就是每天会撞上的摩擦。
Codex++ 干的事，就是把这些摩擦一个个补上。
它不是 Codex 替代品
先把定位说清楚。
Codex++ 不是另一个 Codex CLI，也不是新的 AI Agent 框架，更不是要替代 Codex App。它更像 Codex App 外面的一层增强壳。
它的基本做法是：不直接修改 Codex App 原始安装文件，而是用外部 launcher 启动 Codex，再通过 Chromium DevTools Protocol 往渲染进程里注入脚本，同时在本地起一个后端，负责设置、会话数据、导出、删除、Zed、worktree、provider 同步这些事情。
简单画一下，大概是这样：
Codex++ launcher
│
├── 启动 Codex App（带调试端口）
├── 通过 CDP 注入 renderer-inject.js
└── 本地后端 127.0.0.1:57321
├── 会话删除 / 撤销 / 导出
├── 中转配置写入
├── provider 同步
├── Zed Remote
└── upstream worktree
这个结构决定了它的气质。
它不是在模型层做增强，而是在桌面壳、配置、数据和界面层做增强。换句话说，它不负责让 Codex “更聪明”，它负责让 Codex App “更像一个能长期工作的工具”。
这两件事差别很大。
模型增强追求回答质量、代码质量、推理能力；桌面增强追求的是工作流连续性、配置可控性、界面补丁和本地状态管理。前者更像大脑，后者更像关节。
Codex++ 明显属于后者。
为什么会长出这种工具
我觉得 Codex++ 的出现并不偶然。
任何一个 AI Coding 客户端，只要用户规模和使用强度上来，都会遇到一个问题：官方产品不可能把所有边角需求都做完。
官方要考虑稳定性、一致性、跨平台体验、普通用户心智，也要避免把界面做得太复杂。所以很多重度用户想要的东西，往往不会第一时间进入主线。
但重度用户又是真的需要。
尤其是 Codex App 一旦被当成日常开发入口，用户很快就会开始要求它处理更复杂的本地状态：会话怎么管理，历史怎么导出，provider 怎么切，工具怎么开关，远程项目怎么识别，编辑器怎么联动。
这时候就会自然长出一类“外围增强工具”。
浏览器有扩展，VS Code 有插件，Obsidian 有社区插件。Codex App 发展到一定阶段，也会有人想给它补一层扩展能力。
Codex++ 的有趣之处在于，它不是通过官方插件系统来做这些事，而是走了一个更工程味、也更脆的路径：外部启动、CDP 注入、本地 bridge。
这条路不优雅，但现实。
因为如果官方没有开放足够的扩展点，你想改界面、接本地数据库、加菜单、劫持一些配置流程，就只能绕到运行时外面去做。
所以我对 Codex++ 的第一层判断是：它不是炫技项目，而是典型的生态缝隙产物。哪里官方没补，哪里高频痛，它就从那里钻进去。
中转注入是最现实的功能
如果只选一个最能代表 Codex++ 现实价值的功能，我会选中转注入。
它解决的是一个很微妙的问题：用户既想保留官方 ChatGPT / Codex 登录态，又想把模型请求切到自定义兼容 API。
这个需求在国内使用环境里尤其常见，但它不是简单的“填一个 API Key”就完事。
因为官方登录态和模型请求并不是同一个东西。
官方登录态负责账号能力、插件入口、一些产品侧权限；API 中转负责模型请求的 Base URL、Key、模型名、协议兼容。很多工具会把这两者混在一起，结果就是：你用了 API Key，某些依赖账号态的能力没了；你保留官方登录，又不好切换请求出口。
Codex++ 的做法是把这两层拆开。
它会在 ~/.codex/config.toml 里写入一个 provider 配置，让模型请求走自定义 Base URL 和 token，同时保留官方登录态的角色。README 里的示例大概是这样：
model_provider = "CodexPlusPlus"
[model_providers.CodexPlusPlus]
name = "CodexPlusPlus"
wire_api = "responses"
requires_openai_auth = true
base_url = "https://example.com/v1"
experimental_bearer_token = "sk-..."
这个设计的核心不是 TOML 怎么写，而是边界怎么切。
ChatGPT / Codex 登录态 -> 账号、产品能力、插件入口
Codex++ 中转配置 -> Base URL、Key、协议、模型
它承认了一个现实：很多用户不是要完全离开官方账号体系，而是想在官方产品体验和自定义模型通道之间做一个混合模式。
这个混合模式很脏，但很好用。
那些小按钮，为什么不是小事
Codex++ 还加了一堆看起来很小的功能：会话删除、撤销、Markdown 导出、项目移动、Timeline、插件入口解锁、顶部菜单、后端状态指示灯。
如果只看功能名字，会觉得有些琐碎。
但 AI Coding 工具的成熟度，最后就是体现在这些琐碎的地方。
真实工作不是一次漂亮的 demo。真实工作里，会话会越来越多，项目路径会变，旧对话需要清理，重要讨论需要导出，失败尝试需要删除，长线程需要快速定位，某次上下文值得留档。
这些事情模型帮不了你。
模型可以写代码，可以解释错误，可以跑测试，但它不能替你把客户端的会话管理体验补好。一个没有删除按钮的会话列表，用久了就是会让人烦。一个不能顺手导出 Markdown 的长对话，用久了就是会让知识沉在客户端里。
Codex++ 做的这些小功能，本质上是在把 Codex App 从“对话工具”往“工作台”方向推。
对话工具只关心当前这轮聊得怎么样。工作台要关心历史、整理、迁移、归档、恢复、导出、状态可见性。
这是两个阶段。
Provider 同步和 worktree，更像工程工具
Codex++ 里还有几个不太适合截图宣传、但挺关键的功能。
一个是 Provider 同步。
它处理的是切换供应商以后，旧会话 metadata、rollout、sqlite、本地状态之间的一致性问题。用户感知到的只是“为什么我切了 provider 以后，旧会话不见了？”但底层其实牵涉配置文件、会话文件、SQLite 数据库、metadata 行、workspace root、rollout 文件路径等一堆东西。
codex-plus-data 里专门有 provider_sync，会扫描 sessions、archived_sessions，处理 SQLite 行，保留备份，还会避免锁冲突。这说明作者不是只在前端加按钮，而是真的在跟 Codex 本地状态结构打交道。
另一个是 upstream worktree。
Codex 原生也可以创建工作区，但如果从当前本地 HEAD 派生，很容易遇到一个问题：本地分支已经旧了。你以为自己从最新 main 开始，实际是从几天前的状态切出去，后面冲突一堆。
Codex++ 的 upstream worktree 思路，是从 upstream/<base-branch> 创建新 worktree，创建前先 fetch 远端分支。等价于先做：
git worktree add -b <new-branch> <worktree-path> upstream/<base-branch>
这个功能看起来很窄，但它对 AI Coding 很重要。
因为 agent 做复杂任务时，worktree 是最自然的隔离单位。让模型尝试一个重构、修一个 bug、跑一个实验，最好不要污染当前主工作区。新建 worktree 如果从正确的上游基线开始，后面的合并和验证都会干净很多。
再加上 Zed Remote 这种编辑器联动，Codex++ 其实已经不只是 UI 补丁了。它在往真实工程流靠：远程开发、独立工作区、上游同步、编辑器打开、本地状态管理。
这些东西如果继续长下去，它可能会从“Codex App 补丁”变成“Codex App 工作流管理器”。
它的边界也很清楚
它有几个边界必须承认。
第一，它依赖 Codex App 的页面结构和本地存储结构。某个 selector 变了，某张 SQLite 表变了，某个 rollout 字段变了，都可能导致功能需要适配。它越深入 Codex App 内部，能力越强，也越容易被上游变化牵动。
第二，它不是官方扩展 API。CDP 注入、本地 bridge、DOM patch 都属于运行时增强。它可以很好用，但不是被官方承诺长期兼容的接口。
第三，中转配置和本地状态管理天然敏感。它会处理 ~/.codex/config.toml、auth.json、本地数据库、API Key、provider 配置。用这种工具，至少要知道它会读写什么文件，备份在哪里，怎么回滚。
第四，它适合重度用户，不一定适合所有人。如果你只是偶尔打开 Codex App 问几个问题，完全没必要装一层增强工具。原生体验足够了。Codex++ 的价值主要在那些把 Codex App 当日常开发入口的人身上：会话多、项目多、provider 多、远程环境多，也需要导出和整理。
最后
Codex++ 值得看，不是因为它每个功能都多么惊天动地，而是因为它代表了 Codex App 生态进入了一个新阶段。
第一阶段，大家关心模型能力：会不会写代码，能不能理解仓库，能不能跑命令。
第二阶段，大家关心 agent 工作流：能不能规划，能不能多轮修复，能不能用 worktree，能不能恢复上下文。
第三阶段，开始关心桌面客户端本身：登录态、provider、插件、会话、导出、本地数据库、远程编辑器、自动更新、运行时扩展。
Codex++ 就站在第三阶段。
如果说 Codex CLI 周边工具解决的是“怎么让 agent 更会干活”，那 Codex++ 解决的是“怎么让 Codex App 更适合被长期使用”。