Codex 更新后浏览器失效：内置浏览器、Chrome 扩展与侧边栏修复记录

Codex 更新后，我遇到了一组看起来像同一个问题、实际上分属三条链路的故障：内置浏览器打不开网页，Codex 找不到 Chrome，Chrome 侧边栏也无法连接桌面应用。

最终确认，这不是网站、账号或普通代理配置导致的，而是更新后本机运行状态与服务注册没有完全同步：内置浏览器使用的 Electron 网络子进程卡住；Chrome 原生消息宿主曾缺少有效注册；当前 Codex 版本对应的 app-server 条目也没有写入服务发现文件。

这篇文章记录现象、判断方法和可重复使用的恢复顺序。涉及内部注册文件的部分只用于定位原因，日常修复应优先使用 Codex 提供的更新、重启和插件重装入口。

故障现象

这次一共出现了三种症状。

1. 内置浏览器无法访问任何网址

Codex 可以创建空白浏览器标签页，但访问本地地址或外部 HTTPS 地址都会超时。与此同时，在终端中使用 curl 访问相同地址是正常的。

这说明网络本身可用，问题更可能位于 Codex 桌面应用内部的浏览器运行时，而不是 DNS、代理或目标网站。

2. Codex 无法控制 Chrome

Chrome 中的 ChatGPT 扩展已经安装并启用，但 Codex 的浏览器列表里没有 Chrome，或者调用时无法建立连接。

这条链路依赖 Chrome Native Messaging。仅仅看到扩展图标并不能证明它已经和桌面应用连通；Windows 注册表、Native Messaging manifest、实际扩展目录和 Codex 版本必须互相匹配。

3. Chrome 侧边栏提示找不到 Codex app-server

侧边栏显示：

Open or update the ChatGPT desktop app

技术详情是：

No compatible Codex app-server entry was found

这时扩展与本机原生宿主之间的基础握手其实可能已经成功，真正失败的是下一步：原生宿主没有找到与当前 Codex 安装版本兼容的 app-server 服务条目。

先按官方顺序恢复

OpenAI 的浏览器扩展故障排查文档给出的恢复顺序很实用，建议先完成以下步骤：

1. 将 ChatGPT/Codex 桌面应用和浏览器扩展更新到最新版本。
2. 完全退出并重新打开桌面应用与浏览器。
3. 新建一个聊天，再测试浏览器连接。
4. 打开桌面应用的 Settings → Computer Use，确认 Chrome 后面显示 Manage。
5. 确认扩展安装在当前实际使用的 Chrome Profile 中。
6. 如果仍然失败，从 Settings → Computer Use 重新安装浏览器插件。
7. 问题持续存在时，用 /feedback 提交问题并附上聊天 ID。

这套顺序会重新触发插件部署、原生宿主注册和服务发现同步。多数更新后的连接问题不需要手工编辑配置文件。

如何判断问题发生在哪一层

如果常规重启和重装没有解决，可以按下面的顺序缩小范围。

检查 Codex 版本和诊断信息

在 PowerShell 中查看 Microsoft Store 安装包版本：

Get-AppxPackage '*Codex*' | Select-Object Name, Version

再运行 Codex 自带诊断：

codex doctor --summary --ascii --no-color

更新后排障时，先记下应用版本很重要。旧版本留下的扩展目录或服务条目，路径看起来仍然存在，却不一定能服务当前版本。

区分系统网络与内置浏览器故障

选择一个已知可访问的本地地址和一个外部地址，在终端中分别测试：

curl.exe -I http://127.0.0.1:5000/
curl.exe -I https://example.com/

如果终端可以访问，而 Codex 内置浏览器只能打开 about:blank，访问 HTTP/HTTPS 都超时，故障范围基本可以收敛到桌面应用的浏览器网络进程。

本次修复中，重启 Codex 的 Electron 网络工具子进程后，应用自动创建了新的网络进程，内置浏览器随即恢复。对普通用户来说，等价且更稳妥的操作是完全退出桌面应用，确认其后台进程已结束，再重新启动。

检查 Chrome Native Messaging 注册

Chrome 扩展连接桌面应用时，会查找原生消息宿主。Windows 上可以只读检查注册位置：

Get-ItemProperty `
  'HKCU:\Software\Google\Chrome\NativeMessagingHosts\com.openai.codexextension'

注册表默认值通常指向一个 JSON manifest。还应确认该文件存在，并且其中引用的宿主程序与当前安装匹配。常见位置类似：

%LOCALAPPDATA%\OpenAI\extension\com.openai.codexextension.json

如果注册项、manifest 或宿主程序缺失，Chrome 里的扩展仍可能显示为“已启用”，但它无法和 Codex 建立本机连接。通过 Settings → Computer Use 重装插件，可以让应用按当前版本重新生成这些内容。

检查 app-server 服务发现条目

当侧边栏明确提示 No compatible Codex app-server entry was found 时，关键文件之一是：

%CODEX_HOME%\chrome-native-hosts-v2.json

本次现场中，扩展发出的 codexRuntime/hello 已经成功，说明 Native Messaging 基础通道可用；随后执行 codexRuntime/ensure 时返回：

no_matching_codex_install

进一步检查发现，服务发现文件中没有当前桌面应用版本对应的有效条目，旧条目又指向已经不存在的安装版本。因此侧边栏知道桌面应用存在，却无法找到能启动的当前 app-server。

重新执行当前版本自带的插件注册流程后，Codex 同时更新了用户目录和 AppData 中的服务条目，并同步了插件所需的 app-server 运行时。再次执行 codexRuntime/ensure 后，本地 app-server 地址成功返回；点击侧边栏的 Try again，聊天界面恢复。

不要直接复制其他电脑上的 chrome-native-hosts-v2.json，也不建议手工拼接条目。文件中的安装路径、版本、校验信息和本机状态有关，写错后会留下更隐蔽的版本错配。优先让当前 Codex 版本通过设置页重新注册。

最终根因

这次故障由两个独立状态叠加造成：

1. 内置浏览器的网络子进程卡住。 空白页能创建，但任何 HTTP/HTTPS 导航都超时；终端网络正常。重启桌面应用的浏览器网络运行时后恢复。
2. 更新后的插件注册没有完全对齐当前 Codex 版本。 Chrome Native Messaging 一度缺少有效注册，修复基础通道后，服务发现文件仍没有当前 app-server 条目，导致 codexRuntime/ensure 返回 no_matching_codex_install。重新运行当前版本的插件注册流程后恢复。

所以，“内置浏览器打不开”“Codex 看不到 Chrome”“Chrome 侧边栏找不到 app-server”不应被当成一个模糊的网络问题。它们分别对应浏览器运行时、原生消息宿主和 app-server 服务发现三层。

为什么更新后容易再次出现

Codex 桌面应用、Chrome 扩展、原生消息宿主和 app-server 都有自己的版本与落盘位置。应用更新时，如果旧进程没有退出、Chrome Profile 中还保留旧扩展目录，或者注册同步在中途没有完成，就可能出现“界面显示已安装，但实际链路仍指向旧版本”的状态。

这也解释了为什么单独重装 Chrome 扩展有时只能解决一半：Native Messaging 恢复后，app-server 服务发现仍可能缺少当前版本条目。反过来，只重启桌面应用也无法修复已经丢失的插件注册。

每次更新后的快速检查

以后更新 Codex 后，我会做四个简单检查：

1. 用内置浏览器打开 https://example.com。
2. 在 Settings → Computer Use 中确认 Chrome 显示 Manage。
3. 打开 Chrome 侧边栏，确认能进入聊天，而不是停在连接提示页。
4. 运行一次 codex doctor --summary --ascii --no-color，保存版本和诊断摘要。

如果其中任何一项失败，就按“完全退出应用和浏览器 → 重新启动 → 从 Computer Use 重装插件”的顺序处理。只有在错误仍然明确指向 Native Messaging 或 no_matching_codex_install 时，才继续检查注册表、manifest 和服务发现文件。

这次修复后的验证结果是：内置浏览器可以访问本地与外部页面，Codex 可以发现并控制 Chrome，Chrome 侧边栏点击 Try again 后正常进入聊天界面。