Codex 第三方 API 用户启用 Browser/Chrome 插件：鉴权分离实战与排障记录

前言

我在 Codex Desktop 中使用第三方 OpenAI 兼容接口作为模型提供方，普通对话和代码任务一直正常，但只要调用 Browser、Chrome Remote Control 或 Computer Use，任务就会立即中断。

最有代表性的报错是：

remote control requires ChatGPT authentication; API key auth is not supported

表面看像是 Chrome 插件、网络或 MCP 服务异常，实际根因是：模型请求的 API 鉴权与Codex 插件所需的 ChatGPT 账号鉴权是两套独立链路。

本文记录从日志定位、配置风险分析、双轨认证改造，到成功读取 Chrome 标签页的完整过程。

安全提示：文中的模型 token、设备码和内部地址均使用占位符。不要公开真实 API Key、ChatGPT access token 或一次性设备码。

一、问题现象

环境大致如下：

• Codex Desktop 自带 CLI：0.144.2
• 系统全局 Codex CLI：0.140.0
• 模型提供方：第三方 OpenAI Responses 兼容接口
• Browser、Chrome 插件：已安装
• 普通模型请求：正常
• Browser/Chrome 控制：失败或直接中断

日志中出现了两个关键信号：

apps_enabled=false

remote control requires ChatGPT authentication; API key auth is not supported

执行登录状态检查：

codex login status

结果显示当前是 API Key 登录，而不是 ChatGPT 账号登录。这说明插件文件虽然已经安装，但运行时没有拿到 ChatGPT 账号认证，无法启用远程浏览器控制能力。

二、为什么第三方 API Key 不能直接驱动插件

第三方模型接口负责模型推理：

Codex -> 第三方 OpenAI 兼容端点 -> 模型响应

Browser、Chrome Remote Control 等能力还依赖另一条链路：

Codex -> OpenAI/ChatGPT 账号认证 -> 插件与远程控制

第三方 API Key 能证明你有权调用第三方模型，却不能证明你拥有对应的 ChatGPT 账号会话、插件资格和控制平面权限。

因此需要同时满足：

用途	认证方式
模型推理	第三方 provider token
Browser/Chrome 插件	ChatGPT 账号登录
本地控制通道	Codex Desktop 自带运行时

三、危险误区：只增加 requires_openai_auth

常见的第三方 provider 配置如下：

model_provider = "bella"

[model_providers.bella]
name = "OpenAI custom"
base_url = "https://example-provider.com/v1"
wire_api = "responses"

[model_providers.bella.http_headers]
Authorization = "Bearer <THIRD_PARTY_TOKEN>"
Content-Type = "application/json"

直觉上的修复方式是直接加入：

requires_openai_auth = true

但这存在风险。在我使用的 Codex 版本中，ChatGPT 认证头与 provider 自定义头的处理顺序可能发生覆盖。继续在 http_headers 中手工设置 Authorization，再启用 requires_openai_auth，可能导致：

1. 第三方模型 token 被 ChatGPT 认证覆盖，模型请求失败。
2. 更严重的是，ChatGPT bearer token 可能被发送到第三方模型端点。

所以不能只改一个布尔值，必须把第三方模型 token 与 ChatGPT 账号认证明确分离。

四、正确的双轨认证配置

先备份：

cp -p ~/.codex/config.toml   ~/.codex/config.toml.backup-$(date +%Y%m%d-%H%M%S)

然后修改 provider：

model_provider = "bella"

[model_providers.bella]
name = "OpenAI custom"
base_url = "https://example-provider.com/v1"
wire_api = "responses"
experimental_bearer_token = "<THIRD_PARTY_TOKEN>"
requires_openai_auth = true

[model_providers.bella.http_headers]
Content-Type = "application/json"

关键变化：

1. 从 http_headers 中删除手写 Authorization。
2. 将第三方 token 放入 provider 专用的 experimental_bearer_token。
3. 设置 requires_openai_auth = true，让 Codex 同时要求 ChatGPT 账号登录。

这样，模型请求继续使用第三方 token，插件能力使用 ChatGPT 账号状态。

token 存储注意事项

experimental_bearer_token 仍会把 token 明文保存在配置文件中。更理想的方式是使用 provider 支持的环境变量字段，例如 env_key。

但 Codex Desktop 从图形界面启动时，不一定继承 shell 环境变量。若使用 env_key，需要确认 Desktop 进程确实能读取该变量，否则模型请求会因缺少 token 失败。

至少应限制配置文件权限：

chmod 600 ~/.codex/config.toml

五、使用 Desktop 自带 CLI 校验

机器上可能同时存在多个 Codex CLI。我的环境中：

/Applications/ChatGPT.app/Contents/Resources/codex  -> 0.144.2
全局 codex                                      -> 0.140.0

如果用旧版全局 CLI 校验新版 Desktop 配置，可能得到误导性结果。

固定使用 App 内置二进制：

APP_CODEX="/Applications/ChatGPT.app/Contents/Resources/codex"

严格解析配置：

"$APP_CODEX" app-server --strict-config --help

然后检查登录状态：

"$APP_CODEX" login status

六、设备码登录 ChatGPT

启动设备授权：

"$APP_CODEX" login --device-auth

终端会输出登录地址和一次性设备码：

https://auth.openai.com/codex/device
一次性设备码：XXXX-XXXXX

在浏览器中打开该地址，登录 ChatGPT 账号并输入设备码。设备码通常约 15 分钟有效，不要截图公开或转发给他人。

授权完成后终端显示：

Successfully logged in

再次验证：

"$APP_CODEX" login status

预期结果：

Logged in using ChatGPT

七、分层验证，避免“看起来修好了”

1. 验证配置解析

"$APP_CODEX" app-server --strict-config --help

应无 TOML 解析错误。

2. 验证第三方模型请求

发起一个最小请求：

"$APP_CODEX" exec --skip-git-repo-check --json   'Reply with exactly: OK'

最终返回 OK，说明第三方 provider token 没有被 ChatGPT 登录覆盖。

3. 验证插件状态

"$APP_CODEX" plugin list
"$APP_CODEX" mcp list

重点确认：

• browser@openai-bundled 已安装并启用。
• Chrome 插件在当前任务中可加载。
• 本地浏览器控制通道可用。
• 登录状态不再是 API Key only。

4. 做真实的只读浏览器测试

不要只看插件列表，最好实际执行只读操作：

• 列出内置 Browser 当前页面。
• 列出 Chrome 已打开标签页。
• 读取标题和 URL，不点击、不提交表单。

最终验证结果：

• 内置 Browser 可以正常连接。
• Chrome 扩展可以正常连接。
• 成功读取到 8 个 Chrome 标签页。
• ChatGPT authentication 报错不再出现。

这才说明认证链路真正恢复，而不只是“插件显示已安装”。

八、另一个容易混淆的警告

最小模型请求成功时，Codex 仍提示第三方 /models 返回格式与新版模型列表 schema 不完全兼容，例如缺少 models 字段。

第三方接口常返回：

{
  "object": "list",
  "data": []
}

而新版 Codex 模型管理器可能期待另一种结构。

该警告影响模型列表刷新，但实际 Responses 推理仍成功返回 OK。应把它与插件鉴权问题分开：

• Browser/Chrome 失败：检查 ChatGPT 登录和 apps_enabled。
• 模型列表刷新失败：检查第三方 /models 兼容性。
• 实际推理失败：检查 provider token、base_url 和 wire_api。

不要因为它们同时出现在日志中，就把两个独立问题混为一谈。

九、推荐排障顺序

以后遇到类似问题，可以按以下顺序定位：

1. 确认使用 Codex Desktop 自带 CLI，而不是旧版全局 CLI。
2. 执行 login status，区分 API Key 与 ChatGPT 登录。
3. 查日志中的 apps_enabled 和 remote control authentication。
4. 执行 plugin list，确认插件安装与启用状态。
5. 执行 mcp list，确认本地控制通道。
6. 检查自定义 provider 是否在 http_headers 中手写 Authorization。
7. 启用 requires_openai_auth 前，先分离 provider token。
8. 使用 device-auth 登录 ChatGPT。
9. 发起最小模型请求，确认第三方模型链路仍正常。
10. 最后执行只读浏览器测试，确认插件链路真实可用。

十、结论

这次问题的核心不是 Chrome 扩展损坏，也不是单纯的网络故障，而是把两类认证误认为同一类认证：

• 第三方 API Key 负责模型调用。
• ChatGPT 账号负责 Browser/Chrome 等插件能力。

正确方案不是放弃第三方 provider，也不是把 ChatGPT access token 填进第三方 Authorization 头，而是建立双轨认证：

第三方 provider token -> 模型请求
ChatGPT device auth    -> 插件与浏览器控制

最重要的安全原则是：不要让 ChatGPT bearer token 有机会被发送到第三方模型端点。

完成 provider token 分离、requires_openai_auth、设备登录和真实浏览器验证后，第三方模型与 Codex 插件可以同时正常工作。

参考

• OpenAI Codex 设备授权：https://auth.openai.com/codex/device

本文基于 Codex Desktop 0.144.2 的实际排查结果。后续版本的字段和认证头处理顺序可能变化，升级后应重新验证。