Codex++（CodexPlusPlus）：给 AI 编程 Agent 装上「管理中枢」

一、从一个真实的痛点说起

如果你每天都在用 Codex、Claude Code、Claude Desktop 和 Grok CLI，你大概率遇到过这样一幕：想换一个模型供应商，得手动去翻 ~/.codex/config.toml；想把 Codex 的上下文窗口调大，不知道该改哪个字段；想让 Claude Code 也用上 Codex 那套 Computer Use 桌面控制能力，发现两个客户端各玩各的；想回看昨天某次对话到底改了什么，只能去翻 SQLite 库。

更麻烦的是，这些工具的官方桌面应用会频繁更新。你精心调好的供应商配置、注入的增强脚本，很可能在下一次 Codex 升级后悄悄失效，然后你花一个下午逐项排查。

Codex++ 就是从这一片混乱里长出来的。BigPizzaV3 在 2026 年 5 月建仓，到 2026 年 10 月 25 日发布 v1.12.1 时，已经积累到 32,589 Star、2,099 Fork、120 位贡献者。它不是又一个 Agent，而是一个给 Agent 用的管理中枢——把 Codex、Claude Code、Claude Desktop、Grok CLI 装进同一个控制台，把供应商切换、会话管理、界面增强、Computer Use 共享、子 Agent 协作这些散落在各处的操作收拢成一个图形界面。

二、背景：Agent 工具链正在「碎片化」

2026 年下半年 AI 编程工具的格局发生了明显变化。Claude Code、Codex CLI、Grok CLI、OpenCode 各自跑通了闭环，开发者开始「多开」——同时挂着两三个 Agent 干活。但这些工具在设计上各自为政：配置文件路径不一样、认证方式不一样、模型列表不一样、上下文窗口管理方式不一样。

Codex++ 的作者选择了最不寻常的一条路：不去重写 Agent，而是做官方应用之上的增强层。它通过 Chrome DevTools Protocol（CDP）注入到官方 Codex 桌面应用的渲染进程，读取并改写 ~/.codex/config.toml 与 auth.json，再把统一的供应商配置翻译成各客户端能理解的格式。关键在于——它不修改任何官方应用的安装文件，所有增强都可以单独开关，关闭增强总开关后，供应商与启动管理照常可用。

管理工具概览页：当前供应商、最近 24 小时请求统计与健康检查，一屏看完

三、一个类比：把 Codex++ 想象成「AI 编程的机柜」

如果把各种 Agent 客户端看成散装服务器，Codex++ 就是一台带统一控制面板的机柜。

• 供应商切换像换电源模块——你换的是底层 API 通道（官方登录 / 官方+API / 纯 API / 聚合供应商），上层 Agent 感知不到；
• 协议转换像转接头——把 OpenAI 格式的第三方中转站翻译成 Codex 期望的形态；
• 请求避震像稳压——模型返回 429 或过载时自动等待重试，而不是把错误甩给你；
• 会话管理像硬盘阵列——扫描、删除撤销、导出、轮次回退都从一个界面完成；
• Computer Use 共享像把显卡接驳到另一台机器——Codex 的桌面与浏览器控制能力，通过 MCP 服务借给 Claude Code、Claude Desktop、DeepSeek Harness 使用。

这种类比的意义在于：它解释了这个项目为什么没有容器化。因为它操作的是本机 GUI 应用的进程注入、系统权限（辅助功能、屏幕录制）和本地加密存储，这些在容器里根本无从谈起。

四、核心功能拆解

4.1 供应商与模型路由

Codex++ 支持四种供应商模式：官方登录（走 ChatGPT/Codex 账号）、官方登录+API（保留官方登录与插件入口，模型请求走兼容 API，不消耗官方额度）、纯 API（自定义 Base URL / Key，无需官方账号）、聚合供应商（多个供应商之间做故障转移与轮转，或用 cpx-供应商ID/模型名 前缀把模型固定路由到指定成员）。

一个相当巧妙的细节是「每模型独立上下文窗口」：在模型名后加方括号后缀即可声明窗口，例如 deepseek-v4-pro[1M]、your-model[200K]。Codex++ 会生成 Codex 原生的 model_catalog_json 文件并注入 config.toml 指针，Codex 客户端运行时按模型识别各自的窗口与自动压缩阈值。这解决了一个真实问题：不同供应商的模型窗口差异巨大，用一个全局值必然有一半模型被浪费或被截断。

4.2 Computer Use 共享

这是 v1.12 系列最有想象力的功能。你在管理界面上给某个客户端点「接入」，它会在该客户端的 MCP 配置里写入指向 Codex++ 本地 MCP 服务的条目，重启客户端后，这个客户端就能调用 Codex 桌面应用的原生 Computer Use 能力，操作桌面与浏览器。

Computer Use 工作原理：AI 客户端经 Codex++ MCP 服务调用 ChatGPT.app 的原生 Computer Use 与 Chrome 扩展

技术上有两套实现路径：macOS 上走 ScreenCaptureKit + objc2 直接取流并驱动原生应用；Windows 上走 Win32 API（WinHttp、UI Automation、HiDpi 等一堆 feature 声明）。README 明确标注目前仅 macOS 支持 Computer Use 接入。

4.3 子 Agent 协作

在 Codex 对话里直接说「让 DeepSeek 实现这个功能」，结果会回到当前对话。这本质上是把另一个 CLI Agent 包装成 Codex 可调用的子工具，配合 docs/agent-collaboration.md 中的配置约定实现。

4.4 界面增强与拓展生态

从供应商配置到界面增强，一个管理工具就够了

注入层位于 assets/inject/renderer-inject/，以编号分片形式组织（如 01-registry.js、91-extension-api.js），改完必须跑 node scripts/assemble-renderer-inject.mjs 重新组装产物。这个设计服务于一个明确的第三方扩展契约：开放 window.codexPlus 接口层给社区用户脚本，但路由默认不开，写能力（/settings/set、/delete）不开放，并有契约测试守住这条线。

拓展市场：浏览社区脚本和工作流工具

除注入外，项目还有一整套外围增强：用量状态栏（速度 / 缓存命中率 / 上下文占用）、光标打字特效、桌宠与鲸鱼挂件、皮肤市场、请求日志与自动重试、Codex 多开（每个供应商一个隔离实例）、微信扫码连接本机 Codex、AI Agent 缓存清理。多开功能在 README 里明确提到 DeepSeek 与智谱 GLM 实例可以单独重启或结束。

五、上手门槛：不是程序员也能用，但不是「零成本」

最省事的路径：去 GitHub Releases 下载 CodexPlusPlus-*-windows-x64-setup.exe 或 CodexPlusPlus-*-macos-universal.dmg，双击安装，打开后确认官方 Codex/ChatGPT 桌面应用路径、选供应商、按需开增强，点「启动 Codex」。全程不需要碰命令行。

从源码构建：需要 Rust 1.85+（edition 2024）和 Node.js，流程是 npm ci → npm run vite:build → cargo build --release。AGENTS.md 里还规定了固定的本地 bundle 路径 dist/local-build/Codex++.app，只替换 Contents/MacOS/CodexPlusPlus 二进制，避免在 LaunchServices 里堆出一排同名应用——这是踩过坑之后写进规范的。

必读的坑：

• 依赖注入的设置需要在界面里重启 Codex 才生效；
• 纯 API 与「官方登录+API」使用不同的认证位置，不要手工在两种模式间复制 auth.json；
• Claude Desktop 退出时会重写自己的配置，接入 Computer Use 前要先完全退出；
• macOS 需要给 ChatGPT 授予辅助功能与屏幕录制权限；
• 官方 Codex 应用更新后，依赖其页面结构、CDP 与本地数据格式的部分功能可能需要跟随适配——这是所有「非侵入式增强」的固有代价。

六、争议与局限

第一，AGPL-3.0-only 是一道高门槛。 项目采用最严格的 copyleft 分发条款，明确要求「通过网络提供修改后版本的源代码义务」。对个人用户无所谓，但对需要在企业内部二次开发并闭源分发的团队，选型前必须让法务过一遍。

第二，赞助商列表非常密集。 README 顶部有十余家 API 中转服务商的赞助横幅，包括 JOJO Code、APIKEY.FUN、RunAPI、FennoAI、百可为AI、七牛云、TokenMy、APINEBULA 等。这个生态本身是开源项目的常见变现方式，但对以「统一管理供应商」为核心卖点、同时大量推荐第三方中转站的项目来说，用户在选型时需要自己分辨：中转站的数据流向、稳定性与计费透明度完全取决于服务方，与项目本身无关。

第三，对官方应用的强耦合是双刃剑。 CDP 注入 + 本地数据库直读这套技术路线效率极高，但也意味着官方应用一次结构性更新就可能让一批功能失效。AGPL 协议、扩展契约测试、版本化注入分片都是作者在对抗这种脆弱性的努力，但风险本身并未消除。

第四，功能广度换来的稳定性代价。 946 个文件、117 个测试文件、251 个 Rust 文件、157 个 TS/TSX 文件、41 个 mjs 脚本，规模已经不小。同步支持 Codex、Claude Code、Claude Desktop、Grok CLI 四条主线，意味着任何一条主线的变动都需要同时改配置生成、启动器与注入逻辑。

第五，Computer Use 的平台限制。 目前仅 macOS 支持，而 Codex 桌面版本身在 Windows 用户群里的基数更大，这意味着最有想象力的一块功能对相当一部分用户暂时不可用。

七、行业意义

Codex++ 代表的趋势可以概括为：AI 编程的下半场，是围绕 Agent 的工具链工程。

当 Codex、Claude Code 这类 Agent 已经能写出可用的代码，开发者之间的效率差距就转移到了「谁把 Agent 管得更好」上——供应商切换是否顺滑、上下文窗口是否按模型精细配置、失败重试是否透明、多 Agent 是否能互相委派、团队能否统一管理密钥与配置。Codex++ 用 32,589 Star 证明了一件事：这类「不生产模型、只生产生产力」的项目，拥有极高的用户粘性和传播效率。

它也折射出开源 AI 生态的一个现实：项目的 Star 增长往往不来自技术突破，而来自「踩到了 Everyone 都有的坑」。从 v1.5 到 v1.7 的 macOS 升级兼容壳、从 v1.7.x 到 v1.12 的供应商聚合与 Computer Use 桥接，每一次迭代都紧跟真实用户反馈——社区健康度 57%、累计 2,138 个 issue 关闭、294 个 PR 合并，说明这是一个活跃且有反馈闭环的项目。

八、给团队的落地建议

如果你们团队已经在用 Codex 或 Claude Code，Codex++ 值得试装一次，尤其是这几个场景：

1. 多人共用多个 API 中转供应商，需要在开发机上做统一管理与故障转移；
2. 同时使用多个 Agent，需要统一的会话管理、导出与审计能力；
3. 想在 Claude Code 里复用 Codex 的 Computer Use 能力（macOS 用户）；
4. 需要在不同模型间精细切换上下文窗口以控制 token 成本。

如果只是单人偶尔用 Codex，直接用官方客户端 + 手改 config.toml 可能更省事。

落地前必查项：AGPL-3.0 的合规影响、赞助商中转服务的数据安全评估、Windows 用户对 Computer Use 不可用的预期管理、以及在官方 Codex 更新后预留的适配工作量。

---

项目地址：https://github.com/BigPizzaV3/CodexPlusPlus ｜ 许可证：AGPL-3.0-only ｜ 最新版本 v1.12.1（2026-10-25）