中转站 API、插件解锁与网络排障
南哥讲 Codex++ 解锁 API Key 模式的插件入口（CDP 注入四步原理），@KyrieCheungYep 讲 Reconnecting 5 次的代理修复——两个中国用户最高频的坑。
开篇：两个最高频的坑
Codex 桌面版有两种登录方式：ChatGPT 账号登录（全功能）和 API Key 模式（适合中转站/第三方 API，便宜）。但选了便宜的路，会撞上两个中国用户最高频的坑：① 插件入口灰掉，提示"需要登录 ChatGPT"；② 每次对话前 Reconnecting 重连 5 次才能用。
以下内容来自两篇原文：南哥《Codex 桌面版用中转站 API 也能装插件了》（微信公众号，2026-05-11）给出 Codex++ 绕过方案；@KyrieCheungYep《Codex 装完每次对话前都要 Reconnecting 5 次》（X，2026-05-05）给出 4 步修法。两篇都只讲一件事：不讲功能，只讲排障。
痛点：API Key 模式的插件入口被锁死
以下来自南哥：他用中转站 API Key 登录 Codex 桌面版，体验不错，但有个事一直很烦——左侧「插件」入口直接灰掉，点进去就提示"需要登录 ChatGPT"。等于便宜的价格，代价是插件市场进不去。
顺带的小痛点：原生会话列表只有「归档」，没有真正的「删除」——想彻底删掉一个会话都做不到。
解决方案是一个开源项目：Codex++（https://github.com/BigPizzaV3/CodexPlusPlus，v1.0.5）。它是一个外部增强启动器，不改 Codex 原始安装文件，从外部注入解锁 UI。
Codex++ 像给上锁的门配了把备用钥匙：不拆门、不换锁，只是从旁边开了一条能进的通道。
Codex++：三步安装，四个开关
以下来自南哥。安装三步（要求 Python 3.11+、已装 Codex App），可复制：
git clone https://github.com/BigPizzaV3/CodexPlusPlus.git && cd CodexPlusPlus
python -m pip install -e.
python -m codex_session_delete launch第三步执行后 Codex 自动打开，插件入口已解锁。可选：python -m codex_session_delete setup——macOS 在 /Applications 生成 Codex++.app，Windows 在桌面生成快捷方式；更新用 python -m codex_session_delete update（启动时也会检查 GitHub Release）。
设置面板四个开关：① 插件选项解锁（API Key 模式可用插件入口）；② 特殊插件强制安装（绕过 "App unavailable" 前端安装禁用）；③ 会话删除（列表悬停显示删除按钮，支持撤销）；④ 原生菜单栏位置（Codex++ 菜单插入顶部原生菜单栏）。「后端连接」状态灯每 5 秒检查一次，断开自动修复。
原理：CDP 注入四步（硬核）
以下来自南哥的原理拆解，全网少见的硬核内容。Codex 桌面版本质是 Electron（底层 Chromium），Codex++ 利用 Chromium DevTools 协议（CDP）向它注入脚本：
① 带调试参数启动：Codex.exe --remote-debugging-port=9229 --remote-allow-origins=http://127.0.0.1:9229；② 请求 http://127.0.0.1:9229/json 拿 target 列表，找到 type 为 page 且 URL 含 "codex" 的主渲染进程；③ 经 WebSocket 用 Runtime.evaluate 注入 renderer-inject.js：监听 DOM 解锁插件 disabled 按钮、会话行注入删除按钮、顶部菜单栏插入设置入口；④ 用 CDP 的 Runtime.addBinding 注册页面全局函数，调用时经 WebSocket 转发给 Python 后端（删除会话需操作本地 SQLite），处理完再 Runtime.evaluate 回传——把 CDP 本身当安全 RPC 通道（不开 HTTP 接口，避免本机其他页面误触发）。
架构三层：渲染进程（renderer-inject.js：解锁插件 UI / 注入删除按钮 / 经 CDP Bridge 调后端）↔ CDP（port 9229）↔ Python Launcher（Helper Server 健康检查 / SQLite 操作 / 用户脚本管理）。Windows watcher 服务每 3 秒探测，无 CDP 的 Codex 进程自动 kill 重拉。
风险评估（南哥原话）：注入即在渲染进程跑自定义 JS，但代码开源、注入脚本就一个文件；只监听 127.0.0.1 不对外；删除有确认弹窗和撤销；不碰 app.asar、不写 DLL，Codex 更新后照常用（除非前端结构大改）；唯一风险是 OpenAI 改前端结构后注入脚本需跟进（项目维护活跃）。
自动代理探测：贴合国内网络
以下来自南哥：值得一提的细节——Codex++ 启动时自动探测代理端口：7897、7890、10809、10808、1080 等常见代理端口轮询一遍。因为插件市场要访问 GitHub 拉技能资源，国内网络常挂，自动探测省掉了手动配代理的麻烦。
这正好衔接到下一篇：@KyrieCheungYep 遇到的就是代理没配好的问题——只不过他是手动修。自动探测（Codex++）和手动配 .env（下一篇）解决的是同一类问题，两种路线并列，你按顺手选。
Reconnecting 5 次：根因与 4 步修复
以下来自 @KyrieCheungYep：Codex 装完，每次对话前都要 Reconnecting 重连 5 次才能对话。根因基本都是代理没配，修法很简单，4 步照抄：
macOS：/Users/你的用户名/.codex；Windows：C:/Users/你的用户名/.codex。Mac 用户找不到目录，按 Shift+CMD+. 显示隐藏文件夹。
易错点：7890 是 Clash 类工具的默认端口，用其他代理工具记得换对应端口；Windows 注意隐藏后缀；实在找不到目录——直接把这段需求贴给 Codex，让它代建。
代理没配就像电话线没插好：Codex 一直在"喂？听得见吗？"地重连。线插好（.env 写对），一次就通。
7890 只是 Clash 类工具的默认端口。如果你用的是其他代理工具，先查它的 HTTP 代理端口再填，填错端口等于没修。
术语翻卡：点卡片看解释
自测一下：点问题展开参考答案
左侧插件入口灰掉，提示"需要登录 ChatGPT"；会话列表只有归档、没有真正的删除。
git clone 仓库、pip install -e.、python -m codex_session_delete launch。不改原始安装文件，是外部注入解锁 UI。
带 --remote-debugging-port=9229 启动 → 请求 /json 找主渲染进程 target → Runtime.evaluate 注入 renderer-inject.js → Runtime.addBinding 注册全局函数当 RPC 通道调 Python 后端。
根因是系统代理没配。修法：进 .codex 目录 → 新建 .env（不是 .env.txt）→ 写入 HTTP_PROXY/HTTPS_PROXY 两行 → 保存并重启 Codex。7890 是 Clash 默认端口，其他代理工具要换对应端口。