Codex++ 接入前核对：同名项目、注入范围与回退边界
对比 Codex++ 桌面增强管理器与同名 CLI 分支的项目资料，给出发行来源、协议能力、最小验证和备份核对清单，不提供未经确认的通用配置。
内容复核中 接入能力待核验，不能将本文视作已经确认可用的配置。 图解为本站原创示意，不是客户端运行截图。
查看教程占位服务地址
- 控制台
https://80321.cn- 创建 Key
https://80321.cn/keys- 钱包充值
https://80321.cn/wallet- 文档站
https://80321.cn/docs.html
以上服务地址仅为教程占位示例，不代表本站已提供控制台、密钥创建、充值或 API 服务。实际接入地址请以正式提供的配置为准。
本页目录
“Codex++”不足以确定客户端
检索发现至少两种不同项目：qqheling/codexplusplus 的 README 将产品描述为 Codex App 的外部增强启动器与管理器，并链接到 BigPizzaV3/CodexPlusPlus 的发行入口；yuguorui/codex-plus 则介绍通过 codex++ 命令运行的 Codex CLI 分支。 两者不是同一个安装包，不能混用 UI 步骤和配置片段。
批次主题没有提供安装包或作者标识，因此本页状态为 pending。官方 OpenAI 客户端与第三方项目也必须区分：第三方作者的 README 可以证明其自身设计，不能成为 OpenAI 对这些增强功能的保证。
先用发行来源缩小范围
打开已安装程序的关于信息或安装包来源，记录作者、仓库、版本及可执行程序名称。桌面管理器的 README 区分静默启动器和 Manager 控制面板，后者负责启动、诊断、修复和增强配置。 如果只有一个叫 Codex++ 的快捷方式，仍应确认它指向哪个程序。
遇到仓库名称跳转，要核对 README 链接与实际发行页是否一致；不要从广告、赞助服务或搜索标题推定发布者。CLI 分支的 README 明确写了独立命令和额外协议能力，看到这些特征应按该分支的版本资料继续，而不是套桌面注入教程。
桌面管理器需要核对的改动
桌面项目通过 Chromium DevTools Protocol 注入增强，并提供 relay injection；其说明区分官方账户功能与模型请求路由，还要求准备用户配置备份。 这意味着管理器可能改变启动过程和配置，不能只把它当成“保存一个 Key 的窗口”。
若确认使用此项目，逐项问清当前版本会写哪个配置文件、如何清除 API 模式、是否保留原登录状态，以及用户脚本是否参与启动。模型列表和上下文窗口也由该项目管理；没有上游能力说明时，不要自己扩大窗口数值。
接入信息先作为核对表
准备实际协议、地址、认证头、模型标识与回退位置，但身份未确定前不应用配置。https://80321.cn/v1 只可作为占位示例，本站没有可供本教程验证的真实接口；密钥与模型示意只能写 YOUR_API_KEY、YOUR_MODEL_ID。
CLI 分支的作者文档列出了 Chat Completions 与 Anthropic Messages 等分支能力。 它们不能直接推导桌面管理器或官方 Codex 的支持范围。本页不提供一个“适用于所有 Codex++”的 TOML，也不猜测按钮路径。
最小请求和停手条件
确认身份、协议与正式入口后，先恢复一个能正常启动的基线，再只发送“不读文件、只返回 OK”的短提示。分别记录管理器是否启动正确程序、有效配置是否变化、认证是否通过、文本是否返回。不要在同一次检查里启用增强脚本、多个模型和仓库写入。
如果发行来源无法对应、配置变化解释不清、清除模式不能恢复原状态，或日志出现账户令牌，应停止并回退备份。提交问题时只给版本、脱敏字段和错误，不交出登录文件。等待具体项目确认，比给同名客户端编一套可运行配置更可靠。