Codex++：专治 Codex 桌面端各种不服

你用 Codex 桌面端写了一上午代码，切到会话列表想清理一下昨天的十几个测试对话，发现菜单里只有”归档”，没有删除。你以为是藏得太深，翻了文档、搜了 Issue，最后确认：官方就是没做删除按钮。

这不是 Bug，是 OpenAI 的产品决策。和它不给 ChatGPT 原生导出功能、不给 API Key 用户开放插件入口一样，属于那种”核心功能做得光鲜，体验细节完全不 care”的风格。最让人烦躁的不是功能缺失，而是一旦接受了这个设定，你会发现还有更多类似的设计在等着你。

插件市场被锁定、API 路由无法可视化管理、切换供应商后旧会话找不着。单个看都不是致命伤，但每天用每天烦，累积起来就是劝退级体验。GitHub 上一个叫 Codex++ 的项目就是被这种琐碎的烦躁逼出来的。

它做的事很纯粹：不修改 Codex 本体，通过外部启动器注入增强脚本，把所有官方欠的体验债一次性还清。这篇文章讲的就是它补了哪些坑、怎么补的、补完之后还有什么风险。

为什么值得关注

Codex++ 的核心价值不是功能数量，是功能命中率。它解决的每一个问题，都是 Codex 桌面端用户实际在用的时候会骂出声的痛点。

插件解锁和会话删除是最直观的。Codex 桌面端在 API Key 模式下，插件入口直接灰掉，点都点不了。Codex++ 通过 CDP 注入绕过了这个检查，让 API Key 用户也能正常使用插件市场。会话删除的逻辑更简单，在 CSS 里注入一个悬停删除按钮，和任何网页版聊天应用一样自然。这两个改动本身没有任何技术门槛，官方不做不是因为做不了，是优先级不在那。

API 中转注入才是真正的杀手功能。Codex 桌面端默认把模型请求发到 OpenAI 服务器，如果你想用自己的中转 API，需要手动编辑 ~/.codex/config.toml，而且切换 ChatGPT 登录态后大概率被覆盖。Codex++ 在管理工具里提供了一个可视化配置页面，填 Base URL、API Key、模型名，一键切换。内部做的事是把配置写入 Codex 的 provider 系统：

model_provider = "CodexPlusPlus"
[model_providers.CodexPlusPlus]
name = "CodexPlusPlus"
wire_api = "responses"
requires_openai_auth = true
base_url = "https://your-proxy.example.com/v1"
experimental_bearer_token = "sk-..."

这个方案的精妙之处在于利用了 Codex 原生的 provider 机制，没有 hack 任何网络层，也没有篡改系统证书。换句话说，Codex 官方更新后只要 provider 格式不变，这功能就不会坏。你可能会问：既然 provider 机制是 Codex 原生支持的，为什么官方自己不做一个可视化配置界面？

供应商同步和 Zed 远程开发集成就属于”小众但刚需”那一类。切换模型供应商后，旧会话不会消失，因为 Codex++ 在切换前会自动备份会话数据库。Zed 集成允许你识别 SSH 远程上下文后直接从 Codex 打开文件到 Zed 编辑器，远程开发党会懂这个功能有多省事。

支撑所有这些功能的是一套干净的技术架构。后端用 Rust，启动器本身不依赖任何运行时环境。管理面板用 Tauri 搭建，前端 React，轻量不臃肿。最关键的注入环节走的是 Chromium DevTools Protocol，在 Codex 的渲染进程里加载 renderer-inject.js，不改 app.asar，不写 DLL，不用管理员权限（Windows 上的安装器除外）。

注入脚本就像一个透明补丁层，浮在 Codex 原生 UI 之上。官方更新 UI 结构时，注入逻辑可能会挂，但不会损坏任何数据，最坏的情况就是暂时退回到无增强状态。这个设计决策比很多同类工具的”直接改源码”方案可靠得多。

社区里有种说法很到位：”Codex++ 不是把 Codex 变成一个新工具，是让 Codex 变成它应该有的样子。”这句话本身没太多信息量，但背后有个判断是准确的：Codex++ 没有贪功能，它克制住了”做一个更好用的 Codex 替代品”的诱惑，老老实实做增强层。这个克制本身就是一种品味。

但光看别人安利不够，自己上手装一下才知道这克制到底值不值。

跑起来看看

安装简单到不需要教程，但有几个坑得说清楚，尤其是 macOS 的 Gatekeeper 拦截和便携版 Codex 的路径检测问题。先去 GitHub Releases 页面下载对应平台的安装包，Windows 选 .exe，macOS Intel 选 x64.dmg，Apple Silicon 选 arm64.dmg。装完之后桌面上会出现两个图标，这可能是唯一让新用户困惑的点。

# Windows (NSIS 安装程序，自动创建桌面和开始菜单快捷方式)
CodexPlusPlus-1.2.32-windows-x64-setup.exe

# macOS Apple Silicon
CodexPlusPlus-1.2.32-macos-arm64.dmg
# macOS Intel
CodexPlusPlus-1.2.32-macos-x64.dmg

两个入口的分工很简单：Codex++ 是日常用的，静默启动，直接拉起 Codex 并注入增强功能，不弹窗、不显示管理界面。Codex++ 管理工具是配置用的，中转设置、脚本管理、更新检查都在这里。习惯了之后你几乎不会点开管理工具，但它不能删，因为切换中转方案和自定义用户脚本都得靠它。

macOS 用户有一个必踩的坑。安装包没有通过 Apple 公证，Gatekeeper 会拦截，提示”已损坏，无法打开”。终端里跑一行命令解决：

sudo xattr -rd com.apple.quarantine /Applications/Codex++\ 管理工具.app
sudo xattr -rd com.apple.quarantine /Applications/Codex++.app

这不是安全问题，是 Apple 的公证流程需要花钱和时间，开源项目通常选择跳过。代码全在 GitHub 上，自己编译也行，没什么好担心的。

Windows 用户需要注意几个常见卡点：

• 便携版 Codex 路径检测：如果你装的是便携版而非安装版 Codex，Codex++ 可能检测不到 Codex 路径，需在管理工具里手动指定可执行文件路径
• 管理员权限：Windows 安装器需要管理员权限，这是 NSIS 安装包的限制，不是注入逻辑的要求
• 杀毒软件误报：部分杀软会将 CDP 注入行为标记为可疑，添加到白名单即可

装好跑通了，接下来该考虑一个更实际的问题：这工具到底适合谁。

什么时候用，什么时候别用

不适合的情况其实比适合的更容易判断。如果你的工作环境要求所有软件必须通过公司安全审计，Codex++ 的 CDP 注入机制可能会让你在安全团队那里过不了关。这不是 Codex++ 的问题，是任何基于运行时注入的工具都面临的困境。另一个不适合的场景是只用 Codex CLI 的用户，桌面端增强器跟你没关系。

有个临界情况值得单独说：你是 Codex 桌面端的轻度用户，每周打开一两次，主要是问问技术问题、偶尔写段小脚本。这种场景下，官方版的残缺体验还不至于让你抓狂，Codex++ 的额外安装维护成本可能大于它带来的便利。但如果你的使用频率从”偶尔”变成”每天”，安装 Codex++ 的时间投资会在三天内回本。

社区怎么样了

只有一个核心维护者是所有同类项目的阿喀琉斯之踵。Bus factor = 1 意味着如果作者突然消失，项目会立刻停摆。好消息是作者在过去几个月的更新节奏非常稳定，几乎每周都有新 Release，Issue 响应也很快。坏消息是这个风险无法被任何社区活跃度指标抵消，它是一个结构性问题。

社区讨论集中在中文圈。Linux DO 上有详细的安装教程和功能讨论帖，知乎上的评测文章”终于不用忍了！Codex 增强神器 Codex++“获得了不少关注，评论区普遍反映”每一个功能都踩在痛点上”。QQ 群 830629290 和 Telegram 频道也在活跃运营，对于那些被某个特定坑卡住的用户来说，进群问一句通常比翻 Issue 更快。

赞助商生态是 Codex++ 一个容易被忽视的信号。README 上列出了 14 个赞助商，包括 JOJO Code、APIKEY.FUN、RunAPI 等 AI API 中转服务商。这不是”项目很火所以有人赞助”的因果关系，很可能反过来：Codex++ 的中转注入功能把大量用户导流到了这些 API 服务商，赞助是流量变现。这个商业模式意味着项目有除开源热情之外的持续维护动力，对用户来说是好消息。

社区数据看完了，该聊点真的了：这个项目到底值不值得你跟。

我的真实看法

Codex++ 是一个很难用”好”或”不好”来评价的项目。它的代码质量不是顶尖的，架构也不算精妙，但它做的每一件事都精准命中了一个被 OpenAI 长期忽视的用户群体：非英语区的、使用 API Key 而非 ChatGPT 订阅的、需要灵活配置模型路由的开发者。

一开始我觉得这类”第三方增强器”的生命周期通常很短。官方加个删除按钮，你的差异化功能就少一半。但翻完 Codex 的 Issue 区和 OpenAI 的产品更新日志之后，我的判断变了：OpenAI 根本没把 Codex 桌面端的体验细节当优先级。插件解锁、API 路由自定义、会话删除这些功能，如果 OpenAI 想做，早就做了。它们没做，不是因为技术难度，是因为这些用户不在 OpenAI 的核心付费路径上。

这就给了 Codex++ 一个相当稳固的生存空间。它不需要跟 OpenAI 赛跑，它只需要跟着 Codex 的更新做适配。而 Codex 的 provider 机制、CDP 协议这些底层接口是属于一旦稳定就不会频繁改动的部分，适配成本其实比看起来低得多。

最大的风险不是 OpenAI 官方抄功能，是 Bus factor。21.5k Stars 的项目只有一位核心维护者，这在开源圈是危险信号。赞助商生态目前看起来是正向的，但赞助的本质是流量变现，不是雇佣关系。如果作者的精力被其他事情占据，更新节奏从”周更”变成”月更”再到”停更”，用户能做的只有 fork。

和同类型的 Codex 增强方案比，Codex++ 最大的差异点是克制。有些方案选择直接改 Codex 的 app.asar 或者封装一个全新的 Electron 壳，功能更多但风险也更大。Codex++ 的 CDP 注入方案更像外科手术：切口小，恢复快，失败了也不会留下后遗症。

趋势上它在快速上升。从 Stars 增速来看，2026 年 4 月还只有几千，到 7 月已经接近两万两千，说明市场对这个需求的认可度在集中爆发。如果作者能在未来三个月解决 Bus factor 问题，哪怕只是引入一个可信的协作者，这个项目的长期前景会比现在看起来健康得多。

资源地址

判断聊完了，说点实际的：如果你现在就想去试试，应该怎么开始。

先用管理工具跑一次

如果你已经在用 Codex 桌面端，直接装。从 Releases 下载安装包，先打开管理工具看一眼中转配置，填上你的 API 地址和 Key，然后关掉，以后只用 Codex++ 静默入口启动。三天之内你会忘了自己还装过一个增强器，但每次想删会话或者切 API 的时候，你会感谢三天前的自己。

如果你还在观望，盯两个指标：Release 更新频率和 Bus factor。更新频率掉到两周以上或者作者始终没有引入协作者，说明项目的可持续性开始出问题。在此之前，这个项目是 Codex 桌面端用户的必装项。

Codex++ 的存在本身就是一个有意思的开源现象：它证明了当一个商业产品在体验细节上躺平的时候，社区会用脚投票，造一个不改变底层、但把体验补到及格线的增强层。这不是一个技术故事，是一个产品故事。