Codex 浏览器无法使用：两种恢复案例

页面明明可见，Codex 却无法控制浏览器。同一台电脑上的两种问题——浏览器连接缺失，以及错误页面残留——需要不同的恢复方式。本文介绍检查顺序与实际恢复的范围。

内置浏览器、Chrome 集成与网络搜索

让 Codex“用浏览器查一下”，并不总是使用同一套机制。先确定哪项功能失败、具体无法执行什么，有助于避免无谓地修改设置。

OpenAI 的官方浏览器文档说明，桌面应用中的 Codex 可以打开内置浏览器、点击、输入和检查页面。文档并未表示 CLI 或 IDE 扩展本身拥有内置浏览器。首先要区分的是在哪里使用 Codex。

内置浏览器使用独立于日常浏览器的配置文件。看到 Chrome 扩展已经安装，不代表内置浏览器的控制连接可用。反过来，内置浏览器能工作，也不会自动共享已有的 Chrome 标签页。OpenAI 对浏览器及配置文件的说明

本次优先调查内置浏览器，并使用 Chrome 检查另一条独立连接路径。页面显示、浏览器连接与特定网站上的操作，没有被简单归为同一个“能用或不能用”的结果。

页面能打开，Codex 却找不到浏览器

调查起因是 Codex 开始报告：以前可以执行的浏览器操作，现在无法执行。应用设置中的浏览器已启用，Chrome 也显示扩展已安装。内置浏览器中确实可以打开页面。

但控制接口的目标列表既无法获取内置浏览器，也无法获取 Chrome。唯一可见的目标属于单独的 MCP Apps 界面。用户看到的页面与 Codex 能控制的目标并不一致。

要确认恢复，除了页面显示，还必须验证 Codex 能获取标签页、读取内容并使用链接。

先区分三种症状

本次这类连接问题，与仅影响一个网站的问题，需要不同的检查。先确定操作在哪一步停止。

不要只说“修复浏览器”，可以明确要求：打开公开页面 → 读取标题 → 点击可见链接 → 返回。这样就不会混淆搜索成功与浏览器点击成功。

另一个只需刷新便恢复的聊天

在另一个开发聊天中，本地服务器停止后留下的“无法访问此网站”页面仍停留在标签页中。即使服务器恢复，Codex 获取该标签页的请求仍因 URL 格式不被允许而遭拒。

常规标签页列表报告的实际 URL 使用data:格式，直接包含 HTML。用户正常刷新同一个标签页后，实际 URL 回到 HTTP，Codex 随即能够读取标题和按钮。无需重启整个应用，也没有修改权限。

这与目标列表中缺少浏览器连接不同。该聊天只验证到内容读取，并未验证进入游戏或操作游戏本身。此前记录的连接路径错误，其内部原因也尚未确定。

恢复前做了哪些修改

这台电脑的 Codex 主目录实际数据原本就在D:\CodexHome。默认的%USERPROFILE%\.codex是指向 D 盘的目录联接，但用户级和系统级CODEX_HOME变量均未设置。

OpenAI 将CODEX_HOME定义为设置、身份验证、日志、会话、技能及相关状态的根目录。我们在这里用它测试直接指定 D 盘已有的实际路径。官方并未将其描述为专用的浏览器修复开关。OpenAI 环境变量文档

1. 停止应用和相关 Codex 进程。确认用户在其他聊天中的工作已结束后，在进程停止时备份数据。
2. 复制主目录等数据，并检查内容。对约 68.6GB、共 445,279 个文件比较数量、大小和修改时间，并核对 144 个重要文件的哈希值。
3. 为一次启动指定 D 盘的实际路径。彻底退出后启动相同版本，确认 Shell 和生成的控制配置引用 D 盘。
4. 分别测试内置浏览器和 Chrome。两者都能获取，页面读取与链接操作成功。
5. 同时检查正常启动。获得批准后设置用户环境变量。从任务栏启动的新实例使用相同路径，并通过同样的操作检查。

这组操作的重点是：没有先把应用本体移到其他盘。浏览器在应用迁移前就已确认恢复。之后迁移时发生了另一项故障，因此本案例不支持把 Windows 应用移动功能当成浏览器修复手段。

我们也没有删除目录联接或手动重写 MCP 配置，只读取启动后生成的配置引用，核对是否符合预期。主目录与应用本体的区别见从 C 盘迁往其他盘的记录。

确认恢复所用的操作

恢复后，我们不只检查浏览器出现在列表中，还实际操作了公开页面。这些检查无需用户登录、购买或上传文件。

我们没有把已有私人 Chrome 标签页的列表保留为文章证据。新建测试标签页足以确认恢复。调查浏览器不需要收集已打开的邮件或公司内网页面。

我们还检查了保存状态。选定项目与备份一致，其中包括 2 个置顶聊天、18 个置顶项目和 63 个本地项目。CLI 登录状态检查也成功，无需重建历史或重新登录。

重启应用不同于重启电脑。前者已检查，电脑重启和未来应用更新后的检查则推迟至用户方便时进行。这里的结果涵盖当时的恢复和正常应用启动。

开始时应避免的操作

在区分浏览器连接、网站及存储位置问题之前就删除应用数据或浏览器配置文件，可能丢失登录状态和设置，也会失去用于比较的证据。本次恢复没有清除全部浏览器数据，也没有重装应用。

恢复旧版浏览器技能也不是我们的标准方案。在所调查的电脑上，旧技能缺失属于转向统一 Computer Use 的一部分。仅缺少旧文件，不足以认定其为故障原因。

我们没有使用未公开的内部设置、修改应用代码或替换可执行文件。更换版本可能看似恢复功能，但就无法像本次一样，在同一版本上进行前后对比。

也无需逐步放宽安全设置，因为内置浏览器与 Chrome 所需权限已启用。允许操作某个网站，与是否信任其内容是两回事。恢复测试应选择不含敏感信息、不会产生重要后果的页面。

仍未恢复时应保留的信息

向支持团队求助或进一步调查时，逐步记录每项操作能进行到哪里，比笼统说“不能用”更有效。本次前后最关键的差异是：原先页面能显示但无法获取控制目标；恢复后连链接跳转都能执行。

• 应用版本，以及使用的是桌面应用、CLI 还是 IDE。
• 症状涉及内置浏览器、Chrome，还是两者都有。
• 能否手动打开页面，Codex 能否读取和点击。
• 只影响单个网站，还是也影响无需登录的公开页面。
• 是否彻底退出并启动新实例，是否使用其他盘或自定义主目录。
• 故障发生时间及实际错误消息。排除包含机密的原始日志。

检查主目录位置时，要区分 Shell 的$env:CODEX_HOME、Windows 用户级设置，以及正在运行的应用所用的值。没有使用自定义存储位置的用户，不必照搬本例把设置指向 D 盘空文件夹。

打不开历史或仅发送时失败，并不一定是浏览器控制问题。根据具体消息，也可以参考已有文章Codex thread not found 与历史记录检查。

基于本案例的检查顺序

先确认在哪里使用 Codex、涉及哪个浏览器。服务器恢复后若仍残留错误页面，先正常刷新该标签页。然后在公开页面分别验证显示、读取和点击。若完全没有浏览器连接，保存工作后再考虑彻底退出并重启应用。自定义迁移过主目录的电脑，也可以检查当前引用的位置。

本机有效的组合是：直接指定 D 盘上既有主目录的实际路径，并在彻底退出后启动应用。恢复可以确认，但不能认定目录联接是唯一原因。逐项检查可回退的改动，比把移动应用或删除数据视为万能修复更实际。

常见问题

我能看到页面，就代表 Codex 可以控制吗？

本机曾经页面可见，却无法作为控制目标获取。还要检查内容读取与链接点击。

安装 Chrome 扩展能修好内置浏览器吗？

内置浏览器与 Chrome 集成走不同路径，需要确认是哪条失败。本次也分别测试了两者。

设置 CODEX_HOME 一定有效吗？

尚未证实。本机同时指定实际路径并彻底退出重启，随后恢复。这并不足以建议存储位置未变化的电脑优先迁移主目录。

必须把应用移到 D 盘才能恢复吗？

浏览器在应用本体迁移前已恢复。移动 Windows 应用与修复浏览器控制是两回事。