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

爱神的箭呵呵

324人浏览 · 2026-07-13 21:53:50

爱神的箭呵呵 · 2026-07-13 21:53:50 发布

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，可能导致：

第三方模型 token 被 ChatGPT 认证覆盖，模型请求失败。
更严重的是，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"

关键变化：

从 http_headers 中删除手写 Authorization。
将第三方 token 放入 provider 专用的 experimental_bearer_token。
设置 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。

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

九、推荐排障顺序

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

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

十、结论

这次问题的核心不是 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 的实际排查结果。后续版本的字段和认证头处理顺序可能变化，升级后应重新验证。

AI Agent技术社区

Agent 垂直技术社区，欢迎活跃、内容共建。

更多推荐

基于BP神经网络的语音特征信号分类研究（Matlab代码实现）

语音信号分类是语音信号处理领域的核心研究方向，广泛应用于语音识别、声纹认证、语音情感分析、智能人机交互等诸多领域。由于语音信号具有非线性、时变性、随机性的复杂特征，传统分类方法难以精准挖掘语音特征与信号类别之间的关联关系，存在分类精度低、抗干扰能力弱、泛化性差等问题。BP神经网络凭借其强大的非线性映射、自适应学习和容错能力，能够有效适配复杂语音特征数据的分类任务。