浏览器出现在列表里。标签页也在，带着标题和 URL。你让 agent 去读页面，返回的却是这一行：
Cannot read properties of undefined (reading 'timeoutMs')扩展装着，连接是通的，但一个标签页都读不了。这个细节最容易骗人：报错不出现在浏览器发现阶段，而是出现在第一个要碰到页面内容的动作上。把症状当成权限问题的人会重装扩展，然后停在完全相同的位置。
这个模式在 2026 年 11 月 4 日到 5 日之间被反复报告：#59276 在 Ubuntu 上，#59494 在 macOS 上并附有 Windows 复现，#59574 是 Ubuntu 上的 VS Code 扩展，#59662 是 CLI 配合指向 Linux 上 Brave 的浏览器扩展。截至 2026 年 11 月 9 日，这些 issue 全部仍然开着。
"Cannot read properties of undefined (reading 'timeoutMs')" 到底是什么意思？
意思是执行浏览器操作的那一层拿到一个没有 timeoutMs 字段的对象，却仍然去读这个字段。JavaScript 会立刻抛出 TypeError，任何请求都还没离开本机。
这就解释了三个让人误判的信号。它不是网络超时，因为失败只花毫秒。它不是权限被拒，因为扩展已经把标签页列表交出来了。它也不是标签页被关闭，因为报错正好发生在 agent 去用刚找到的那个标签页的时候。
怎么用三次调用确认是这个错误，而不是别的？
把发现和动作分开看。发现能工作，动作会崩。如果两个都崩，你的问题是另一回事，这篇文章不适用。
// 1. 发现：扩展、配置文件和标签页
await cua.getState()
// 2. 绑定一个已存在的标签页
const tab = await cua.getTab(tabId, { browser })
// 3. 标签页内容
await tab.domSnapshot()在 #59494 里，提交报告的人描述的是同一个形状：绑定一个已存在的 HTTPS 标签页和尝试快照，都在访问到任何内容之前返回 TypeError。在 2026 年 11 月 8 日的一份 Windows 10 复现里，cua.getTab 立即失败，标签页只能通过另一条路径，也就是浏览器直连 API，返回 URL。在同一次复现里，domSnapshot()、screenshot() 和显式传入 timeoutMs 的只读 evaluate 都抛出同一个 TypeError，这就排除了默认值没填好的猜测。
| 信号 | 它证明什么 |
|---|---|
cua.getState() 返回扩展、配置文件和带标题、URL 的标签页 | 通往浏览器的桥是活的 |
cua.getTab() 立刻抛 TypeError | 问题在动作层，不在发现层 |
domSnapshot()、screenshot() 和 evaluate 以同样方式失败 | 不是某个函数坏了，是整个层 |
| 从调用到失败只有毫秒级 | 不是网络，不是页面加载，不是超时 |
安装包来自发行版仓库时，怎么修？
先比较已安装的版本和仓库提供的版本。#59276 的报告里，已安装的是 26.1013.31256，而仓库里已经有 26.1029.61003，随包插件也在同一构建上。
apt policy chatgpt输出里有两行关键信息：Installed 和 Candidate。如果候选版本高于已安装版本，说明新版本已经发布，只是应用没告诉你。
sudo apt update
sudo apt install --only-upgrade chatgpt升级之后关掉应用再打开。报告里通过的验证脚本就是这个顺序：
- 新建一个临时标签页，导航到一个公开网址。
- 读取这个标签页的内容。
- 点击一个可见链接，确认导航确实发生了，再读取目标页面。
- 用同一个
cua.getTab去读取之前失败的那个标签页。 - 关掉这个临时标签页。
报告明确写了没做什么：没有重置配置文件，没有清 cookie，没有打 native host 补丁，也没有换到另一套自动化栈。
为什么"没有可用更新"并不代表你已经是最新版？
因为那个更新检查回答的问题比你想问的窄。它把你的构建和某个公共端点上公布的版本做比较，并不会去问你的包管理器。
在 codex doctor 的源码里，updates.status 这个检查按渠道和平台拼出端点列表：GitHub releases、Homebrew cask 的 API、macOS 的 appcast，以及 Windows 上的 windows-store-update.json。文件头部的注释自己写着：这个检查从不执行包管理器，也不执行 PATH 里的辅助程序，npm 的更新目标会标记为未检查。列表里没有针对 Linux 发行版包的端点。
codex doctor --json如果 updates.status 那行显示 latest version status: current version is not older，请这样读：那个渠道没有公布更新的版本。不要读成：我的安装是最新的。在让问题解决的那份报告里，应用内更新器说的"不可用"根本不是对仓库的查询，而 APT 早就提供了下一个版本。
同一个修复对 VS Code 扩展也有效吗？
无效。在 #59574 中，扩展 26.1007.21434 能列出标签页，但一附加就失败。尝试升级到 VS Code 列表里最新的 26.1021.22027，装上之后 Codex 界面直接打不开。退回 26.1007.21434，界面回来了，TypeError 也一起回来了。
在 Windows 上，升级之后问题同样复现：2026 年 11 月 7 日的一份报告使用 26.1021.31345，仍然看到 TypeError；11 月 8 日另一份在 Windows 10、包版本 26.1013.4894.0 上复现了相同行为。
| 使用面 | 报告中的版本 | 升级解决了吗？ |
|---|---|---|
| Ubuntu 桌面应用，发行版包 | 26.1013.31256 升到 26.1029.61003 | 是，并通过五步验证 |
| Ubuntu 上的 VS Code 扩展 | 26.1007.21434 升到 26.1021.22027 | 否：新版本打不开界面，旧版本继续报错 |
| macOS 桌面应用 | 连接和列表都正常 | #59494 中没有确认的修复 |
| Windows 桌面应用 | 26.1021.31345，2026-11-07 | 否，之后再次复现 |
| Windows 10 桌面应用 | 26.1013.4894.0，2026-11-08 | 否，之后再次复现 |
为什么 agent 会说浏览器不见了，而它其实还在？
因为有两个诊断陷阱会造成同样的误报，两个都出现在 #59276 的后续跟进里。
第一个是调用了不属于这个扩展的工具。有个 agent 试了 chrome-devtools.list_pages，收到 Missing X server to start the headful browser。那个集成要自己启动一个带图形界面的浏览器，所以它的报错跟已经打开的扩展连接毫无关系。
第二个是从不完整的清单里推断出"不存在"。另一个 agent 在 functions.exec 的 ALL_TOOLS 里找 cua_repl，没找到，就宣布工具不存在。computer use 插件的 .mcp.json 里写着 omit_tools_from: ["code_mode", "deferred"]，也就是说这个工具是被故意排除在那份清单之外的。直接调用 mcp__cua_repl.js，浏览器出现了，页面也读到了。这次假性复发没有用重启、重装或重置配置文件来解决。
由此得出的规则是：确认活着的依据是读到一个页面，不是列出标签页。列标签页只能证明扩展在跟应用说话。
哪些尝试不值得再做一遍？
#59276 的报告列出了升级解决之前已经试过的所有操作。下面这些全部无效：
| 尝试 | 结果 |
|---|---|
| 重启整台机器 | 错误依旧 |
| 更新独立 CLI | 错误依旧 |
| 新开一个 CUA 会话 | 错误依旧 |
| 禁用并重新启用 Chrome 扩展 | 错误依旧 |
| 检查 Chrome 扩展更新 | 版本没有变化 |
| 重装浏览器插件 | 发现功能回来了，读取在半秒左右再次失败 |
注意这个模式：六次尝试动了所有东西，唯独没动应用的构建。回报恰好来自那个没人换过的部件。
在问题解决之前还能继续干活吗？
能，把工作分成两堆。需要已登录标签页的部分先停住，因为没有哪次提示词调整能换回 CUA 层根本没有交付的读取结果。不需要浏览器的部分在终端里继续跑，包括换个方式抓取页面，再把内容作为文本交给 agent。
在提交 issue 之前，先把诊断已经给出的东西记下来：cua.getState() 的输出、应用版本、随包插件版本，以及 codex doctor --json 的结果。这四项信息决定了你的报告是往前推进，还是变成又一轮重装。
通往浏览器的桥断掉时，决定你这一天的是有多少工作还能不依赖它继续推进。在 Verboo Code 里，会话跑在终端中，/doctor 把安装诊断、版本、更新、沙箱和 MCP 提醒放在同一块屏幕上，你不必再猜是哪一层坏了。配合无限 token，每次升级之后重跑那套五步验证，不会额外多付一次费用。
