如果你经常使用 Codex App，可能很快就会遇到两个很现实的问题。

第一个问题是，使用 API Key 登录时，原生插件入口往往不可用，界面会提示需要登录 ChatGPT，很多插件能力也就跟着“锁住”了。

第二个问题是，Codex 原生的会话列表里通常只有归档，没有真正意义上的删除。对于重度用户来说，历史会话越积越多，管理起来并不轻松。

最近看到一个项目，叫 Codex++。它的目标非常直接，就是在不修改 Codex App 原始安装文件的前提下，对 Codex 做一层外部增强，补上这些原生缺失但又很常用的能力。
即使你使用的是 API Key 登录，也可以把原本不可用的插件入口重新解锁出来。

项目地址：

Codex++ 是什么？

Codex++ 可以理解为一个面向 Codex App 的外部增强启动器。

它不是去改 Codex 的 app.asar，也不是往安装目录里硬写补丁文件，而是通过一种更“外围”的方式工作：

  1. 用外部 launcher 启动 Codex
  2. 给 Codex 附加远程调试参数
  3. 通过 Chromium DevTools Protocol 注入增强脚本
  4. 在页面层补充菜单、按钮和一些交互能力

换句话说，它更像是在 Codex 外面包了一层增强逻辑，而不是直接篡改原程序本体。

它解决了什么问题？

从项目当前的实现来看，Codex++ 主要做了几件事。

1. 解锁插件入口

这是它最吸引人的功能之一。

在 API Key 登录模式下，Codex 原生前端会把插件入口视为不可用。Codex++ 的做法，是在渲染层注入脚本，调整前端状态判断，让界面重新显示并启用插件入口。

对用户来说，最直接的效果就是：
原本灰掉或不可点的插件入口，被重新“点亮”了。
image.png

2. 增加真正的会话删除

Codex++ 会在会话列表悬停时显示“删除”按钮，并且删除前会弹确认框，删除后还支持撤销。

这一点对会话管理很实用。尤其是当你把 Codex 当作长期工作台使用时，历史线程会非常多，归档并不总是等于整理，真正删除能力会更符合不少人的习惯。

3. 优先服务端删除，失败时回退本地删除

这个设计其实很有意思。

它不是简单粗暴地只删本地数据，而是优先尝试服务端接口；如果服务端不可用，再回退到本地 SQLite 存储删除。并且在本地删除前会先做备份，所以还能支持撤销。

这说明它不只是“做个按钮”，而是把删除这件事当成了一个相对完整的功能链路去实现。

4. 提供 Codex++ 菜单和开关面板

项目还在顶部增加了一个 Codex++ 菜单，用来统一管理开关项，比如：

  • 插件选项解锁
  • 特殊插件强制安装
  • 会话删除
  • 菜单栏位置调整

这让它不只是一个单点脚本，而更像一个可配置的小型增强层。

它是怎么工作的？

Codex++ 的整体架构并不复杂，但思路很清晰。

一端是 Python 写的 launcher 和本地 helper 服务，负责启动 Codex、建立桥接、处理删除与撤销逻辑。

另一端是注入到页面里的 JavaScript，负责直接修改前端界面，比如：

  • 找到插件入口按钮
  • 调整按钮禁用状态
  • 添加“删除”按钮
  • 增加菜单和设置面板
  • 监听页面重渲染后重新挂载增强逻辑

这种方式的好处是：

  • 不直接改原始安装文件
  • 部署成本相对低
  • 功能扩展比较灵活

但它也有天然局限：

  • 一旦 Codex 前端结构变化，注入脚本就可能失效
  • 这种增强方式对页面 DOM、类名、React 结构会比较敏感
  • 稳定性会受到上游版本更新影响

所以它更适合被理解成一种“外部增强工具”，而不是一个官方支持的扩展机制。

需要注意什么？

这类项目的价值很明显，但也有几点值得提前说明。

第一，它终究是第三方增强工具，不是官方功能。
第二，它依赖注入和前端结构识别，上游改版后可能需要同步更新。
第三，如果你对稳定性、安全性、兼容性要求非常高，使用前最好先了解它的工作方式，并做好自己的数据备份。

不过从设计思路来看，Codex++ 已经尽量避免直接修改原始安装内容，这一点是比较克制的。

标签: none

添加新评论