OpenAI Chrome 插件试用时遇到的 Codex 浏览器问题

最近开始试 OpenAI / Codex 的 Chrome 插件。

我本来只是想看看它能不能接管本机 Chrome。结果一用就发现不对：@Chrome 连不上。更奇怪的是，@Browser 也不太稳定。

一开始我以为是 Chrome 插件的问题。后来查下来，不是。

Chrome 插件只是最先报错的地方。更具体的问题在 Codex 的浏览器运行时，以及这些运行时发起网络请求时，是否真的经过了代理。

下面这篇不是完整日志。我把关键检查结果写出来，方便以后遇到类似问题时少绕一点路。

问题是什么

当时的情况大概是这样：

@Chrome 连接超时。
@Browser 也有异常，内置浏览器页面能显示，但自动化接口不稳定。
Node REPL 能执行普通 JavaScript。
终端 curl 可以访问外网。
Node fetch 访问外网失败。
nodeRepl.fetch 会一直等待，不是正常返回，也不是快速失败。

如果只有 @Chrome 出问题，我会先查 Chrome 扩展、native host、Chrome profile。

但 @Chrome 和 @Browser 都有问题，就不能只看 Chrome 插件。它们有共同依赖的部分，尤其是 Browser Use 的运行时。

Chrome 插件检查结果

先查 Chrome 这边。

检查结果基本都正常：

Google Chrome running: yes
Chrome installed: yes
Codex Chrome Extension installed: true
Codex Chrome Extension enabled: true
Extension version: 1.1.4_0
Native host manifest exists: true
Native host manifest correct: true

插件自带脚本也能打开 Chrome 窗口。

所以，Chrome 没开、扩展没装、扩展没启用、native host manifest 写错，这些都可以先排除。

真正失败的是后面的连接过程：Codex 通过扩展创建浏览器会话时超时。

也就是说，问题从“扩展有没有装好”，变成了“扩展后面依赖的运行时为什么没有回应”。

Node REPL 和网络请求的结果

接着看 Node REPL。

普通 JavaScript 可以执行。模块也能 import。比如简单计算、读取运行目录，都没问题。

但 Browser Use 和 Chrome 插件都会用到的 browser-client setup 会卡住。

我把几种网络路径分开测了一下，结果不一样：

curl https://chatgpt.com/backend-api/me
结果：能返回 HTTP 响应，但走的是代理环境变量。

Node fetch https://chatgpt.com/backend-api/me
结果：fetch failed。

nodeRepl.fetch https://chatgpt.com/backend-api/me
结果：长时间没有返回，AbortController 也没能中止。

这几个结果很重要。

curl 能访问，只能说明 shell 里的 curl 这条路径能访问。它不能代表 Node fetch，也不能代表 Codex 浏览器运行时。

我之前把这些路径混在了一起。实际排查时，它们要分开看。

代理变量只能解决一部分问题

代理变量一开始也有写错的地方。

小写变量当时变成了这种值：

http_proxy=_PROXY
https_proxy=_PROXY
all_proxy=_PROXY
no_proxy=_PROXY

后来在 ~/.codex/.env 里改成显式写法：

HTTP_PROXY=http://127.0.0.1:10803
HTTPS_PROXY=http://127.0.0.1:10003
ALL_PROXY=http://127.0.0.1:10803
NO_PROXY=localhost,127.0.0.1,::1
http_proxy=http://127.0.0.1:10803
https_proxy=http://127.0.0.1:10003
all_proxy=http://127.0.0.1:10803
no_proxy=localhost,127.0.0.1,::1

然后从终端启动 Codex：

/Applications/Codex.app/Contents/MacOS/Codex

这样 Codex 主进程和一部分子进程可以读到这些环境变量。

但这只能解决会读取 HTTP_PROXY / HTTPS_PROXY 的程序。不是所有网络请求都会看这些变量。

所以这里的结论要保守一点：代理变量写对是必要的，但不一定够。

v2rayN 的 TUN 模式解决了网络问题

后面开启 v2rayN 的 TUN 模式，再重新启动 Codex。

这次 nodeRepl.fetch 可以正常返回：

nodeRepl.fetch https://chatgpt.com/backend-api/me
结果：HTTP 200

然后再测浏览器能力：

Browser backends:
- Chrome
- Codex In-app Browser

@Chrome test:
打开 https://example.com/
title: Example Domain
heading count: 1

到这里，@Chrome 恢复正常。

所以这次有效的处理不是重装 Chrome 插件，而是让那些不读取代理环境变量的请求也能经过代理。

在这个环境里，TUN 比单独写 HTTP_PROXY 更可靠。

代理变量仍然可以保留，因为有些子进程会用到。只是这次的问题不能只靠它解决。

@Browser 剩下的是另一个问题

网络恢复后，@Chrome 正常了。

@Browser 还有问题。

当时我在内置浏览器里看到过一个奇怪状态：地址栏是 about:blank，但页面内容显示的是 Example Domain。

后来手动把地址栏改成 https://example.com/，显示内容和地址栏同步了。

但自动化接口仍然可能返回：

No active Codex browser pane available

我又试了几种操作：

browser.tabs.selected()
结果：No active Codex browser pane available

browser.tabs.list()
结果：No active Codex browser pane available

browser.tabs.new()
结果：No active Codex browser pane available

这说明 @Browser 剩下的问题已经不是代理，而是 Codex 的 in-app browser pane 没有被 Browser Use 后端正确识别。

这里要分开看两件事：

页面能显示，是 WebView 的状态。

自动化接口能操作页面，是 Browser Use 后端的状态。

这两件事不一定同时成立。

现在的判断

我现在比较确定的是：

Chrome 插件本身不是主要原因。
Chrome 扩展、native host、Chrome 运行状态都正常。
@Chrome 之前失败，是因为 Browser Use runtime 初始化时的网络请求没有正常返回。
v2rayN 的 TUN 模式解决了这个网络问题。
@Browser 剩下的问题应该继续从 in-app browser pane 绑定去查。

最开始这个问题很模糊：好像 Chrome 插件有问题，好像 Browser Use 有问题，好像 Node 也有问题。

拆开以后，它变成了几个更具体的问题：

Chrome 插件没有明显异常。

Node REPL 可以运行。

fetch 和代理之间有问题。

TUN 能解决这部分网络问题。

Browser pane 还需要单独处理。

这比一开始清楚很多。

下次我会按这个顺序查

如果以后再遇到类似问题，我会这样查：

确认 Node REPL 能执行简单 JS。
测 nodeRepl.fetch 能不能访问 chatgpt.com/backend-api/me。
检查 ~/.codex/.env 里的大小写代理变量。
如果 curl 能访问，但 fetch 不能访问，不要直接认为代理已经没问题。
开 TUN 或系统代理，再重启 Codex。
再测 @Chrome 的扩展、native host、浏览器会话。
最后看 @Browser 的 pane 是否能被自动化接口识别。

这次对我有用的不是某个具体命令，而是这个拆分方式。

一个地方报错，不等于那个地方就是原因。先把问题拆成几个可以单独验证的部分，再看哪一部分真的不对。