Codex 报错 The browser access host is unavailable：CLI 暂无修复

The browser access host is unavailable 是什么情况：先看入口

这行报错的意思是：Codex 的浏览器工具在找到任何浏览器之前就失败了，返回的浏览器列表是空的，错误写的是 Browsers: Error: The browser access host is unavailable。同一行报错，出在哪个入口，处理办法完全不同：

ChatGPT 桌面版就是很多人说的"Codex 桌面版""Codex app"，Windows 里的安装包名仍是 OpenAI.Codex。下面按这三条路线分开讲。

codex cli 和 IDE 插件里报错：官方文档本来就写着不支持

OpenAI 的 Browser 文档第一句就是：Browser isn't available in Codex CLI or the Codex IDE extension，要用内置浏览器请打开 ChatGPT 桌面版。浏览器扩展文档也写明，Chrome、Edge、Brave、Opera、Vivaldi 的 ChatGPT 扩展是"从 ChatGPT 桌面版"使用的。

那为什么很多人觉得是"更新后坏了"？按用户报告，10 月中旬之前，在终端或 IDE 里调用桌面版自带的浏览器插件是能用的，@Browser 和 @Chrome 都行。GitHub 上的报告标题就写着"以前能用的 Chrome 访问现在失败"（#59300），讨论最多的 #57641 标题是"桌面版更新到 26.1023.6123.0 后，终端 CLI 的 @Browser 报 The browser access host is unavailable"。这种用法本来就不在文档支持的范围内，现在断了，OpenAI 也没有承诺恢复。

哪些场景报告过这条错

下面都是 GitHub 上的用户报告，不是 OpenAI 的说明：

• 终端 Codex CLI 的 @Browser：Windows 11（#57641）、macOS CLI 0.167.0（#60130）
• codex exec 调用 Chrome 扩展：macOS CLI 0.166.0（#59592）
• VS Code 的 Codex 插件，同一台电脑上桌面版浏览器正常（#58916）
• JetBrains 通过 codex-acp 使用、T3 Code、Paseo、Orca 这类第三方宿主（#56928、#57641 的评论）
• Claude Code 的 Codex 插件 /codex:rescue（codex-plugin-cc #839）
• SSH 远程项目：Windows 连 Linux（#59925）、Linux EC2（#60459）

这些报告里有一个几乎一致的现象：同一台电脑上，在 ChatGPT 桌面版里新开的对话照样能用同一个浏览器。坏掉的只是"从桌面版以外启动的会话去借用桌面版浏览器"这条路。

用户分析的原因：访问凭据只给桌面版启动的进程

OpenAI 没有解释原因，下面是可以从安装文件和用户分析里看到的部分。桌面版 26.1103.60933 自带的 unified-computer-use 插件，在启动浏览器工具 cua_repl 时要传入三个环境变量：BROWSER_USE_ACCESS_EXECUTOR_ID、BROWSER_USE_ACCESS_PIPE_PATH、BROWSER_USE_ACCESS_VERIFYING_IDENTITY。有用户在 VS Code 终端里跑 codex doctor --json，发现这几个变量都缺失（#58916）；#57641 和 #56928 里的分析也认为，管道路径和验证身份只有桌面版自己拉起的进程才拿得到。从终端、IDE 或宿主启动的会话缺少这些凭据，访问检查直接失败，于是返回这行报错。

这能解释为什么在 CLI 这边怎么折腾都没用：问题不在你的浏览器、扩展或 CLI 版本，而在会话是谁启动的。

截至 2026 年 11 月 11 日：OpenAI 未回复，没有修复版本

• issue 数量：从 10 月 19 日起（最早见于 #55173），openai/codex 仓库里提到这条报错的独立 issue 已有 20 多个，#57641 有 34 个反应和 50 条评论，除一个被标为重复外全部未关闭。
• 官方回复：这些 issue 里没有一条 OpenAI 维护者的回复，只有机器人的查重评论。有用户在 #56928 里说，OpenAI 的 AI 客服收集完日志后，把他指回了这个 GitHub issue。
• 修复版本：没有。Codex CLI 0.167.0（11 月 6 日）和 0.167.1（11 月 10 日）的发布说明都没有提到浏览器访问；更新日志页上 26.1007 之后也没有桌面版的发布说明。
• 未知：OpenAI 是否打算恢复 CLI 和 IDE 的浏览器访问、什么时候恢复，都没有公开信息。

2026 年 11 月 11 日实测：最新桌面版 26.1103.60933 仍报错

测试环境是 macOS 26.1（Apple 芯片），ChatGPT 桌面版 26.1103.60933 正在运行并已登录，自带的 chrome 和 unified-computer-use 插件也是 26.1103.60933，Codex CLI 0.166.0。北京时间 12:30，用 codex exec -s read-only 让 Codex 只调用一次 await cua.getState()，不打开任何标签页，返回结果是：

{"browsers":[],"errors":["Browsers: Error: The browser access host is unavailable"]}

这说明报告里出现过的最新桌面版并没有修好 CLI 这条路。这只是一台电脑上的一次测试，没有测 CLI 0.167.x，也没有测同一台电脑上桌面版对话的表现。

codex cli 报这条错怎么解决：五步检查顺序

CLI、codex exec、IDE 插件、第三方宿主和 SSH 远程项目都按这个顺序：

1. 确认会话不是桌面版启动的。 看你输入任务的窗口：终端、VS Code 侧栏、JetBrains、T3 Code、Claude Code 都属于这条路。哪怕桌面版正开着，从这些地方发起的会话也拿不到浏览器访问。
2. 在 ChatGPT 桌面版里确认浏览器本身没问题。 在桌面版新开一个 Codex 或 Work 对话，用 @Browser 或 @Chrome 打开一个网页。能打开，就说明问题只在 CLI 这条路，下面的桌面版检查顺序不用再做。
3. 把需要浏览器的那一步搬到桌面版对话里。 这是 OpenAI 文档本来的用法：在桌面版里打开同一个项目，让它完成登录、查看页面、截图这类步骤；写代码、跑测试仍可以留在终端。
4. 只是需要一个浏览器、不需要 ChatGPT 扩展时，用独立的浏览器工具。 有用户报告 Playwright MCP 在 VS Code Codex 插件和 CLI 0.166.0 里能正常导航、截图（#58916），Chrome DevTools MCP 1.12.0 加 --autoConnect 在 Orca 里的 CLI 0.166.0 能列出标签页、读取页面（#56928）。它们不走 ChatGPT 扩展，权限也是各自的一套；连到你日常登录的浏览器资料时，等于把这个资料里的登录态交给了它。
5. 记下版本号，到 #57641 补充信息。 具体要带哪些，见文末"反馈"一节。

这些做法已有人试过，对 CLI 路线无效

以下来自 #57641 和 #56928 里的用户报告，先列出来，免得你再花时间：

• 把 CLI 回退到 0.164.0
• 重装桌面版和 CLI，加 --no-daemon，整机重启
• 在配置里覆盖 env_vars
• 更新 Chrome 和 Codex、重置 CUA 运行环境或 CUA REPL
• 先启动桌面版，再从 CLI 发起任务
• 把 VS Code 里开的对话放到桌面版里打开继续
• 换模型

网上流传的非官方绕过：能用，但跳过了访问检查

#57641 里有用户贴出几种绕过办法：在 ~/.codex/config.toml 里另写一份去掉访问检查预加载的 cua_repl 配置、通过 node_repl 直接调用 Chrome 插件里的浏览器初始化函数、改插件自带的预加载脚本，还有第三方写的桥接仓库。OpenAI 没有认可其中任何一种。

它们的共同代价是：绕开的正是浏览器访问检查本身，而这个检查决定了谁能操作你已登录的浏览器。另外，有用户报告桌面版每次启动都会删掉 config.toml 里的覆盖配置，插件一更新，改过的文件也会被换掉，所以这些办法随时会失效。

桌面版 @Browser 报这条错：先更新，再彻底重开

这条报错也出现在 ChatGPT 桌面版自己的对话里，只是报告少得多。比如 #55173（macOS 26.1013.40934）里，内置浏览器的标签页明明开着，Codex 调用浏览器工具却拿到空列表和这行报错；#56928（macOS 26.1021.31345）也是类似情况。

在桌面版里遇到时，按这个顺序：

1. 更新桌面版。 电脑上装了不止一个 ChatGPT 或 Codex 桌面应用时，每个都要更新，或者删掉不用的副本（这一条来自 OpenAI 的浏览器扩展排查说明）。
2. 彻底退出再打开。 不是关掉窗口，而是退出整个应用：macOS 用菜单退出，Windows 在任务管理器里结束进程。
3. 开一个新的 Work 或 Codex 对话再试。OpenAI 文档的说法是，新对话可以清掉旧对话里的连接状态。
4. 还是不行，在应用里运行 /feedback，联系支持时附上对话 ID。

有一个可参考的恢复案例：#58856 里有用户在 11 月 4 日报告，Windows 桌面版更新到 26.1029.7803.0、彻底关闭再打开后，Work 和 Codex 两种桌面对话都恢复了浏览器控制，但同一台电脑上 VS Code 里的 Codex 仍然报错。这是一位用户的经历，不是 OpenAI 确认的修复，但它和上面的顺序一致，也再次说明 IDE 那条路是另一回事。

@Chrome 浏览器扩展连不上：按 OpenAI 的检查顺序逐项查

在桌面版对话里用 @Chrome、@Edge、@Brave 等调用浏览器扩展时报这条错（如 #59756、Windows 上的 #58856），按 OpenAI 浏览器扩展文档里"ChatGPT 连不上你的浏览器"的排查顺序走。这份清单没有点名这行报错，但它就是官方给扩展连接问题的处理办法：

1. 先确认 ChatGPT 要访问的网站不在设置里的黑名单（blocklist）上。
2. 更新 ChatGPT 桌面版；装了多个 ChatGPT 或 Codex 桌面应用的，每个都更新或删掉不用的。
3. 重启浏览器。Chrome、Edge、Brave、Vivaldi 从工具栏或扩展菜单重新打开 ChatGPT，确认侧边栏对话能加载；Opera 没有侧边栏，在桌面版里检查连接。
4. 打开桌面版的 Settings > Computer Use 页面，确认你的浏览器显示 Manage。如果还显示 Install，说明扩展没装好，重走一遍安装流程。
5. 浏览器不在 @ 菜单里时，打开它在 Computer Use 里的开关。
6. 确认你用的是装了扩展的那个浏览器资料（profile）。有多个资料时，要在当前使用的资料里安装并启用扩展。
7. 开一个新的 Work 或 Codex 对话再试，可以清掉旧对话的连接状态。
8. 重启 ChatGPT 桌面版；还连不上，就在 Settings > Computer Use 里重装扩展。
9. 仍然失败，在应用里运行 /feedback，联系支持时附上对话 ID。

注意，如果 @Chrome 是从终端、codex exec 或 IDE 里调用的（比如 #59592），它属于上面 CLI 那条路，这份清单帮不上忙。另外，官方文档也提到，浏览器扩展能否使用"可能取决于推送进度和你的工作区设置"。

不是这条报错：几条容易混淆的提示

报错文字不一样，原因和处理办法也不一样：

论坛上有人把这条报错说成"浏览器访问被拒绝"，指的通常就是 The browser access host is unavailable，按开头的入口表判断即可。

反馈 The browser access host is unavailable 时带上这些版本号

OpenAI 文档给的正式渠道是在应用里运行 /feedback，联系支持时附上对话 ID。CLI 和 IDE 这条路，新开的 issue 通常会被机器人标成 #57641 的重复，直接在 #57641 里补充更有用。补充时带上：

只写"我也一样"帮助不大，带上版本组合和"桌面版对话里能不能用"这一项，才能让维护者看出哪个版本开始出问题。

关于这条报错的几个问题

回退 Codex CLI 版本能解决 The browser access host is unavailable 吗？

目前没有成功的报告。#57641 里有用户把 CLI 回退到 0.164.0，问题依旧。用户分析认为卡点在会话是否由桌面版启动，和 CLI 版本关系不大。

是不是我的 Chrome 扩展没装好？

在 CLI 或 IDE 里报错时，多半不是。先在桌面版对话里用 @Chrome 试一次：能用，说明扩展没问题；也报错或显示 Install，再按上面的扩展检查顺序处理。

哪个版本修好了这个问题？

截至 2026 年 11 月 11 日没有。CLI 0.167.0、0.167.1 的发布说明都没有提到，相关 issue 里没有 OpenAI 的回复；在桌面版 26.1103.60933 加 CLI 0.166.0 上实测仍然报错。之后如果 OpenAI 在 issue 或发布说明里给出修复版本，以那里为准。