[yiliang114]

What this PR does

createBrowserBackend() deliberately skips Native Messaging Host registration when the platform is not darwin/linux, but the runtime it returned still carried the transport's own 35s connect budget. This PR lifts that registration condition into two named predicates (hasManagedEndpointOverride(), supportsNativeHostRegistration()) and reuses them so the transport is built with UNREGISTERABLE_HOST_CONNECT_TIMEOUT_MS (0) exactly when registration was impossible and nothing else publishes an endpoint. The call graph, the returned runtime and every error message are unchanged — only the wait disappears.

Why it's needed

Fixes #13692. On such a platform every wait polls for a host that provably cannot exist: browsers.get('chrome') blocks ~35s before the honest message appears, the named-profile path in the bundled skill pays it twice (~70s), and setupBrowserRuntime() clears its singleton on failure so each agent retry pays it again. The reporter measured LIST {"resolved":[],"elapsedMs":35001} and GET {"threw":true,"code":"BROWSER_DISCONNECTED","elapsedMs":35001} straight from the transport's ?? 35_000 default with POLL_INTERVAL_MS = 100.

The guard is conditioned on the same thing registration is, not on the platform alone, per the ruling in the resolved R1-3 thread on #13675. !explicitSocketPath inside the transport is not an equivalent condition — it derives only from options.socketPath ?? QWEN_BROWSER_USE_SOCKET_PATH and ignores QWEN_BROWSER_USE_DISCOVERY_DIR, so a discovery-dir-only setup can legitimately connect and must keep its full budget. Both cases are pinned by tests here.

Interaction with #13675: zero file overlap — #13675 touches 0 lines of packages/browser-use/src/runtime.ts, and this PR touches none of the files #13675 edits. Failing fast by throwing from createBrowserBackend() was rejected on purpose: #13675 is still open and reworded the disconnect error via disconnectedMessage(platform), and an early throw would make that win32 branch dead in production. Passing a near-zero connect budget instead keeps connectWithinDeadline() on the path that produces the reworded message, so the two PRs compose in either merge order.

Reviewer Test Plan

How to verify

The defect only occurs when process.platform ∉ {darwin, linux}, so a real unmocked reproduction is impossible on a Linux or macOS host, and the Windows CI lane cannot substitute: ci.yml gates test_windows on merge_group / schedule / workflow_dispatch, not on pull_request. There is no on-Windows witness in this PR. The reproduction is a deterministic, platform-stubbed test-level one — the same form #13675 already runs green on Linux CI — using the file's existing vi.useFakeTimers(), with discoverChromeProfiles mocked to publish nothing so the wait can only end at its deadline. The poll loop, the deadline arithmetic and the platform guard stay the real ones, and the 35s figure comes from the transport's own constants, not from a hard-coded expectation.

cd packages/browser-use
npx vitest run src/runtime.test.ts

New cases (all appended after the existing it.each, nothing re-ordered, beforeEach/afterEach untouched):

• lists no browsers at once where no Native Host can be registered — win32 + both env vars empty: dispatch('browsers.list') settles within the window and still resolves [].
• rejects a start at once where no Native Host can be registered — same setup: dispatch('browsers.get') settles within the window and still rejects BROWSER_DISCONNECTED.
• still waits out the connect budget for a managed QWEN_BROWSER_USE_SOCKET_PATH / _DISCOVERY_DIR on such a platform — win32 with a managed override: installer.ensure uncalled and the wait is not short-circuited.
• still waits out the connect budget where a Native Host is registered — linux, both env vars empty: registration happens and the wait is unchanged.

No test wall-clock-waits: everything runs under fake timers and the whole file finishes in ~26ms of test time, so it stays inside the 5s off-pool testTimeout (packages/browser-use is in OFF_POOL_DEFAULT).

Evidence (Before & After)

Before (source unpatched, new tests present) — the two fail-fast cases hang for the whole observation window:

 FAIL  src/runtime.test.ts > createBrowserBackend > lists no browsers at once where no Native Host can be registered
AssertionError: expected NaN to be less than or equal to 1000
 FAIL  src/runtime.test.ts > createBrowserBackend > rejects a start at once where no Native Host can be registered
AssertionError: expected NaN to be less than or equal to 1000
 Test Files  1 failed (1)
      Tests  2 failed | 12 passed | 1 skipped (15)

After (same tests, patched runtime.ts):

 ✓ src/runtime.test.ts (15 tests | 1 skipped) 26ms
 Test Files  1 passed (1)
      Tests  14 passed | 1 skipped (15)

The three "still waits out the budget" cases pass both before and after — that is the point: they pin that the guard does not fire for a managed endpoint or for a registrable platform.

Tested on

OS	Status
🍏 macOS	⚠️ not tested (defect cannot occur there; darwin path pinned by the existing cases)
🪟 Windows	⚠️ not tested — no Windows host available, and test_windows does not run on pull_request. The win32 behaviour is covered by stubbing process.platform.
🐧 Linux	✅ tested (unit tests below)

Environment (optional)

N/A — unit tests only, run in a worktree off origin/main 29aef7de40b752bb0464919ab4af8f08a988dd31.

Commands run, with results:

Command (cwd)	Result
npx vitest run src/runtime.test.ts (packages/browser-use)	exit 0 — 14 passed, 1 skipped (15)
npx vitest run src/bridge/transport/chrome-extension-transport.test.ts (packages/browser-use)	exit 0 — 26 passed (26), unmodified file
npx vitest run (whole packages/browser-use)	exit 0 — 24 files, 583 passed, 9 skipped (592)
npx tsc --noEmit (packages/browser-use, i.e. its typecheck script)	exit 0, no diagnostics
npx eslint src/runtime.ts src/runtime.test.ts	exit 0, no findings
npx prettier --write on both changed files	both reported unchanged

Risk & Scope

• Main risk or tradeoff: the observable contract is preserved but the timing is not — profiles() still resolves [] and start() still rejects BROWSER_DISCONNECTED with the Web Store text, they just stop taking ~35s. A setup where something else registers a Native Messaging Host on a non-darwin/linux platform and publishes to the default discovery directory would lose its wait; that setup cannot exist today, because registration itself is gated on the same platform list.
• Not validated / out of scope: no Windows host run, and no change to the transport's ?? 35_000 default, to POLL_INTERVAL_MS, or to setupBrowserRuntime()'s singleton reset in packages/core's bundled skill. Only packages/browser-use/src/runtime.ts and packages/browser-use/src/runtime.test.ts are touched (no vitest.config.ts change).
• Breaking changes / migration notes: none. createBrowserBackend() keeps its signature and its failure modes.

Linked Issues

Fixes #13692

Related, non-overlapping: #13675 (reworded disconnect message, still open), #13663 (parent report).

中文说明

这个 PR 做了什么

createBrowserBackend() 在平台不是 darwin/linux 时会故意跳过 Native Messaging Host 注册，但它返回的 runtime 仍然带着 transport 自己的 35 秒连接预算。本 PR 把那段注册条件抽成两个具名谓词（hasManagedEndpointOverride()、supportsNativeHostRegistration()）并复用它们，只有在「注册不可能」且「没有别的来源发布 endpoint」时，才用 UNREGISTERABLE_HOST_CONNECT_TIMEOUT_MS（0）构造 transport。调用图、返回的 runtime、所有错误文案都没变，消失的只有那段等待。

为什么需要

修复 #13692。在这类平台上，每次等待都在轮询一个证明不可能存在的 Host：browsers.get('chrome') 要卡约 35 秒才给出诚实的报错，bundled skill 的具名 profile 路径要付两次（约 70 秒），而 setupBrowserRuntime() 失败时会清掉单例，所以 agent 每次重试都要再付一次。报告者直接按 transport 的 ?? 35_000 默认值与 POLL_INTERVAL_MS = 100 测到 LIST {"resolved":[],"elapsedMs":35001}、GET {"threw":true,"code":"BROWSER_DISCONNECTED","elapsedMs":35001}。

按照 #13675 上已 resolve 的 R1-3 讨论中的裁决，这个守卫的条件必须与注册的条件一致，而不是只看平台。transport 内部的 !explicitSocketPath 并不等价——它只来自 options.socketPath ?? QWEN_BROWSER_USE_SOCKET_PATH，忽略了 QWEN_BROWSER_USE_DISCOVERY_DIR，因此只配了 discovery 目录的场景是可以正常连接的，必须保留完整预算。两种情况这里都有测试钉住。

与 #13675 的关系： 文件零重叠——#13675 对 packages/browser-use/src/runtime.ts 改了 0 行，本 PR 也没有碰 #13675 改的任何文件。我们刻意没有选择「从 createBrowserBackend() 直接抛错」：#13675 仍未合并，它通过 disconnectedMessage(platform) 重写了断连文案，提前抛错会让那个 win32 分支在生产中变成死代码。改为传入接近 0 的连接预算，connectWithinDeadline() 仍然走在产出那段新文案的路径上，两个 PR 无论谁先合都能组合。

评审测试计划

如何验证

缺陷只在 process.platform ∉ {darwin, linux} 时出现，所以在 Linux / macOS 主机上无法做真实未 mock 的复现，Windows CI 也顶不上：ci.yml 里 test_windows 只在 merge_group / schedule / workflow_dispatch 下跑，不在 pull_request 下跑。本 PR 没有 Windows 实机见证。 复现是确定性的、平台打桩的测试级复现——与 #13675 已在 Linux CI 上跑绿的形式一致——复用该文件既有的 vi.useFakeTimers()，并把 discoverChromeProfiles mock 成不发布任何 endpoint，于是这段等待只能在自己的 deadline 上结束。轮询循环、deadline 计算与平台守卫都是真实代码，35 秒这个数字来自 transport 自己的常量，而不是写死的期望值。

新增用例（全部追加在既有 it.each 之后，没有重排，beforeEach/afterEach 未改）：

• lists no browsers at once where no Native Host can be registered —— win32 + 两个环境变量都为空：dispatch('browsers.list') 在窗口内结束，且仍然 resolve []。
• rejects a start at once where no Native Host can be registered —— 同样的设置：dispatch('browsers.get') 在窗口内结束，且仍然以 BROWSER_DISCONNECTED reject。
• still waits out the connect budget for a managed QWEN_BROWSER_USE_SOCKET_PATH / _DISCOVERY_DIR on such a platform —— win32 且存在托管 override：installer.ensure 不被调用，等待也没有被短路。
• still waits out the connect budget where a Native Host is registered —— linux + 两个环境变量为空：注册照常发生，等待时长不变。

没有任何测试按真实时钟等待：全部走 fake timers，整个文件的测试耗时约 26ms，因此稳稳落在离池时 5 秒的 testTimeout 之内（packages/browser-use 在 OFF_POOL_DEFAULT 里）。

前后证据

修复前（源码未打补丁、新测试已就位）——两个 fail-fast 用例在整个观测窗口内都没有结束：

 FAIL  src/runtime.test.ts > createBrowserBackend > lists no browsers at once where no Native Host can be registered
AssertionError: expected NaN to be less than or equal to 1000
 FAIL  src/runtime.test.ts > createBrowserBackend > rejects a start at once where no Native Host can be registered
AssertionError: expected NaN to be less than or equal to 1000
 Test Files  1 failed (1)
      Tests  2 failed | 12 passed | 1 skipped (15)

修复后（同样的测试，runtime.ts 已打补丁）：

 ✓ src/runtime.test.ts (15 tests | 1 skipped) 26ms
 Test Files  1 passed (1)
      Tests  14 passed | 1 skipped (15)

三个 "still waits out the budget" 用例在修复前后都通过——这正是重点：它们钉住「托管 endpoint 或可注册平台上守卫不触发」。

测试环境

OS	状态
🍏 macOS	⚠️ 未测试（该缺陷在 macOS 上不可能出现；darwin 路径由既有用例钉住）
🪟 Windows	⚠️ 未测试 —— 没有可用的 Windows 主机，且 test_windows 不在 pull_request 上运行。win32 行为通过打桩 process.platform 覆盖。
🐧 Linux	✅ 已测试（下面的单元测试）

环境（可选）

N/A —— 只跑单元测试，在基于 origin/main 29aef7de40b752bb0464919ab4af8f08a988dd31 的 worktree 中执行。

实际执行的命令与结果见上方英文表格（逐条一致）。

风险与范围

• 主要风险/取舍：可观测契约保留，但时序变了——profiles() 仍然 resolve []，start() 仍然以带 Web Store 文案的 BROWSER_DISCONNECTED reject，只是不再花约 35 秒。如果存在「由别的程序在非 darwin/linux 平台上注册 Native Messaging Host 并发布到默认 discovery 目录」的场景，它会失去这段等待；但今天这种场景不可能存在，因为注册本身就受同一份平台清单限制。
• 未验证 / 不在范围内：没有 Windows 实机运行；没有改 transport 的 ?? 35_000 默认值、POLL_INTERVAL_MS，也没有改 packages/core bundled skill 里 setupBrowserRuntime() 的单例重置。只碰了 packages/browser-use/src/runtime.ts 与 packages/browser-use/src/runtime.test.ts（没有改 vitest.config.ts）。
• 破坏性变更 / 迁移说明：无。createBrowserBackend() 的签名与失败模式保持不变。

关联 Issue

Fixes #13692

相关但零重叠：#13675（重写断连文案，仍未合并）、#13663（父报告）。

[qwen-code-review-bot]

✅ Qwen Triage finished — CI landed green on 1397b12 and the deferred approval was posted. finalize run

✅ Qwen Triage 已完成 —— 1397b12 的 CI 全绿，延迟审批已提交。查看 finalize 运行

[qwen-code-review-bot]

Thanks for the PR — easy to follow, and the reasoning in the description held up against the source.

Template ✓ every required section is filled in, including the Tested-on table and a real before/after.

Problem — observed, not theoretical. #13692 is open, labelled type/bug + priority/P2, and carries measurements taken off the transport's own defaults (LIST {"resolved":[],"elapsedMs":35001}, GET {"threw":true,"code":"BROWSER_DISCONNECTED","elapsedMs":35001}), independently confirmed against 2e962b61 in the issue thread. I re-checked the mechanism at the reviewed commit: the transport was built with { describeProfiles } only, so connectTimeoutMs fell through to the ?? 35_000 default, and both wait sites poll against that budget. Waiting 35s for a host that cannot be registered is real.

Direction — aligned. The condition the guard uses is the one the docs already publish as policy ("Native Host installation currently supports macOS and Linux", docs/design/browser-use.md), so this doesn't invent a new platform stance. CHANGELOG: no browser-use or Native Messaging reference (that surface is ours), but the shape is one upstream ships — "Fixed MCP connections hanging for the full 30-second connect timeout when a server fails to answer", plus a fail-fast fix for fetches that used to block on a prompt. Sequencing against #13675 checks out: I pulled its diff, and the two PRs share zero files.

Size — not applicable: no core-infrastructure path (packages/browser-use/src/**, one package, no cross-package edit). For reference, 41 production lines (runtime.ts +35/−6) against 108 test lines.

Approach — scope feels right, and I'd have landed in about the same place: the decision belongs in the backend factory, since that's the only spot that knows both that registration was skipped and whether a managed override publishes an endpoint. Pushing the platform check down into the transport would be worse — it has no business knowing the installer's policy, and !explicitSocketPath genuinely isn't equivalent, because it ignores QWEN_BROWSER_USE_DISCOVERY_DIR. Throwing early from the factory would have stranded #13675's reworded win32 message; passing a budget instead keeps that path alive, and the two compose in either merge order. Two claims I verified rather than took on faith: options.connectTimeoutMs ?? 35_000 preserves an explicit 0 (nullish, not falsy), and both wait sites are do-at-least-once, so one discovery pass still runs and the disconnect still carries the Web Store text. The SDK context the bundled skill drives goes through this same factory, so the named-profile double-pay is covered too.

One question, not a blocker. The guard is keyed on registration, not on what discovery actually finds, so the residual case is a live record in the default discovery dir on a non-registrable platform. Your Risk section says that can't exist because registration is gated on the same platform list — nearly true, but the host/discovery/protocol stack below the installer is win32-aware (profileSocketPath builds a named pipe, verifySocketPeerPath no-ops there, chromeDiscoveryDirectory() has its own win32 root), so a hand-written registry key can get a host published without our installer ever running. Under a 0 budget that setup would still list the profile, but connectHost() receives Math.max(1, deadline - Date.now()) = 1ms for the hello handshake — it fails instead of connecting. That's unsupported by the design doc and #13675 is about to report it as such, so I wouldn't add code for it; a clause in the comment above the constant would be enough, since "provably nothing to wait for" is the claim that quietly stops holding there.

Risk — no elevated risk signals: neither file matches the revert-correlated paths.

Moving on to code review. 🔍

中文说明

感谢贡献！这个 PR 很好读，描述里的推理和源码对得上。

模板 ✓ 必填章节都写全了，包括 Tested-on 表格和真实的 before/after。

问题——是已观测到的 bug，不是理论性加固。#13692 仍为 open，带 type/bug + priority/P2 标签，并给出了直接基于 transport 默认值的实测数据（LIST {"resolved":[],"elapsedMs":35001}、GET {"threw":true,"code":"BROWSER_DISCONNECTED","elapsedMs":35001}），issue 里也有人对着 2e962b61 独立确认过。我在被审查的那个 commit 上复核了机制：transport 只带 { describeProfiles } 构造，connectTimeoutMs 落到 ?? 35_000 默认值，两处等待都按这个预算轮询。为一个不可能注册成功的 Host 等 35 秒，确实存在。

方向——对齐。守卫所用的条件正是文档已经公布的策略（docs/design/browser-use.md：「Native Host installation currently supports macOS and Linux」），所以这不是新造一个平台立场。CHANGELOG：没有 browser-use 或 Native Messaging 的直接条目（这块是我们自己的面），但同类形态上游是发的——「Fixed MCP connections hanging for the full 30-second connect timeout when a server fails to answer」，以及把原本卡在提示上的 fetch 改成 fail fast。与 #13675 的排序也没问题：我拉了它的 diff，两个 PR 文件零重叠。

规模——不适用：没有触及核心基础设施路径（packages/browser-use/src/**，单一 package，无跨包改动）。供参考：生产代码 41 行（runtime.ts +35/−6），测试 108 行。

方案——范围合理，我自己也会走到差不多的位置：这个判断就该放在 backend 工厂里，因为只有那里同时知道「注册被跳过」和「是否有托管 override 在发布 endpoint」。把平台判断下推到 transport 更差——它不该知道安装器的平台策略，而且 !explicitSocketPath 确实不等价，它忽略了 QWEN_BROWSER_USE_DISCOVERY_DIR。从工厂里提前抛错会让 #13675 重写的 win32 文案变成死代码；改成传预算就把那条路径留住了，两个 PR 无论谁先合都能组合。有两个说法我是去核实而不是照单接受的：options.connectTimeoutMs ?? 35_000 会保留显式的 0（nullish 判断，不是 falsy 判断）；两处等待都是 do-at-least-once，所以仍会做一次 discovery，断连也仍带 Web Store 文案。bundled skill 走的 SDK context 同样经过这个工厂，所以具名 profile 的「付两次」也被覆盖了。

一个疑问，不是阻塞项。守卫的依据是「能否注册」，而不是 discovery 实际发现了什么，所以剩下的情形是：在不可注册的平台上，默认 discovery 目录里出现了一条存活记录。Risk 一节说这种情形不可能存在，因为注册受同一份平台清单限制——基本成立，但安装器之下的 host/discovery/protocol 栈是 win32-aware 的（profileSocketPath 构造命名管道、verifySocketPeerPath 在 win32 上直接返回、chromeDiscoveryDirectory() 有自己的 win32 根目录），所以手写一个注册表项就能在我们的安装器从未运行的情况下发布 Host。在 0 预算下，这种配置仍能列出 profile，但 connectHost() 拿到的 hello 握手预算是 Math.max(1, deadline - Date.now()) = 1ms——于是变成连不上。这在设计文档里本来就不支持，#13675 也正要把它报成不支持，所以我不建议为此加代码；在常量上方的注释里补一句就够了，因为「provably nothing to wait for」正是那里会悄悄不成立的说法。

风险——无升级风险信号：两个文件都不匹配与 revert 相关的高风险路径。

进入代码审查 🔍

— Qwen Code · qwen3.8-max-2026-09-02

_{Reviewed at 1397b1249487b34403e89d40a960cb1cc9caa485 · re-run with @qwen-code /triage}

[qwen-code-review-bot]

Code review

Read against 1397b124. No blockers — the change is small, the reasoning in the description survives contact with the source, and the tests are genuinely discriminating rather than decorative.

What I checked instead of assuming:

• An explicit 0 survives the transport. this.connectTimeoutMs = options.connectTimeoutMs ?? 35_000 is nullish, not falsy, so the guard's 0 is not silently swallowed back into the 35s default. The undefined arm is fine too: the root tsconfig sets strict but not exactOptionalPropertyTypes, so connectTimeoutMs?: number accepts an explicit undefined.
• The field has exactly two consumers (profiles() and connectWithinDeadline(), both deadline arithmetic). requestTimeoutMs is untouched, so nothing about an already-connected session changes.
• A 0 budget removes the polling, not the check. profiles() compares Date.now() >= deadline, so one discovery pass still runs before it returns [] — an endpoint published between construction and call is still found. connectWithinDeadline() is a do…while, so one attempt still happens and the final throw still carries the Web Store text. That is also what keeps fix(browser-use): report Windows as unsupported instead of advising an install #13675's disconnectedMessage(platform) branch reachable in production; I pulled that PR's diff and the composition argument holds (zero shared files, and the reworded throw is the one this path lands on).
• The guard reaches the path that pays twice. createBrowserSdkContext() → createBrowserBackend(), so the bundled skill's named-profile flow (browsers.list() then browsers.get(id), per its SKILL.md) is covered by the same change rather than needing a second fix at the call site.
• The tests pin all four quadrants and would go red on an over-broad guard. This is the part I expected to be weak and it isn't: under fake timers, a wrongly-applied 0 budget makes connectHost's own setTimeout(…, Math.max(1, deadline - Date.now())) a 1ms timer that fires inside advanceTimersByTimeAsync(1_000), so the three "still waits out the budget" pins would settle and fail — they aren't passing vacuously. Keying the guard on platform alone, or dropping QWEN_BROWSER_USE_DISCOVERY_DIR from managed, both turn something red. The vi.hoisted discovery mock is the pattern AGENTS.md asks for, and it keeps the tests off the runner's filesystem (no prepareDiscoveryDirectory mkdir). Statically, the two fail-fast assertions cannot pass on unpatched source (settledAfterMs stays NaN, and NaN <= 1000 is false), which matches the before-output in the description — that output is the author's, I did not re-run it.

Non-blocking, both already touched in Stage 1:

1. The residual case is a live record in the default discovery dir on a non-registrable platform. The stack below the installer is win32-aware, so a hand-written registry key can produce one without our installer running; under a 0 budget that setup lists the profile but gets a 1ms hello handshake, so it fails instead of connecting. Unsupported per the design doc and about to be reported as such by fix(browser-use): report Windows as unsupported instead of advising an install #13675, so no code needed — but the comment above the constant currently asserts "provably nothing to wait for", which is the one place that claim quietly stops holding.
2. hasManagedEndpointOverride() and supportsNativeHostRegistration() are each called exactly once, two lines apart. Inlining them as const managed = … / const registrable = … under the existing comment would carry the same meaning with less indirection, which is what AGENTS.md's "no abstractions for single-use code" points at. The names do document the platform list, so it's a judgement call, not a defect.

Test evidence

Unattended CI run — I did not build, run, or check out anything from this PR. What follows is the PR's own CI, fetched from the API for the reviewed commit, plus the static verification above.

Not verified: any behaviour on a real Windows host. No lane witnesses it — test_windows and test_macos are gated to merge_group / schedule / workflow_dispatch in ci.yml (confirmed in the file, and both report skipped here), and the defect cannot occur on Linux or macOS in the first place. The merge queue will run the same platform-stubbed tests on a Windows runner, which is a weak witness at best: the tests stub process.platform, so what the real host adds is only the win32 arms of chromeDiscoveryDirectory() / profileSocketPath() / verifySocketPeerPath().

Final CI results for 1397b12 (auto-updated by the triage finalize job after CI completed):

Check	Conclusion
Classify PR	✅ success
Desktop Shell (ubuntu-22.04)	✅ success
Desktop Shell (windows-2022)	✅ success
Integration Tests (no-AK, No Sandbox)	✅ success
Lint & Static (ubuntu-latest, Node 22.x)	✅ success
Test (ubuntu-latest, Node 22.x)	✅ success
web-shell E2E Smoke (ubuntu-latest, Node 22.x)	✅ success

_{One row per check name (latest run); skipped checks omitted; failures sort first. / 每个检查名一行（取最新一次运行），省略 skipped，失败项排在最前。}

26 check-runs on this commit, 0 failures at the time of writing. The lane that matters — Test (ubuntu-latest, Node 22.x), which installs (running the workspace prepare build) and runs the suite including packages/browser-use/src/runtime.test.ts — was still in progress, so the unit result is not in yet; review-pr and triage are bot orchestration, not PR CI. Lint & Static is green, and that lane builds the workspace before its bundle-closure and subpath-export steps, so a compile error on this path would most likely have surfaced there already. Nothing here is red, so there is no failing-job log to quote.

Sandboxed verification would settle the one claim CI cannot: @qwen-code /verify — the unit lane witnesses the stubbed-platform fail-fast, but nothing exercises the residual case from note 1, i.e. whether a discovered endpoint on a non-registrable platform still connects now that connectHost() receives a 1ms hello budget instead of ~35s. A /verify A/B against the base build could pin that behaviour; the author has write access, so no sponsored run is needed. /tmux is the wrong lane here — nothing in this diff is a TUI surface.

中文说明

代码审查

对着 1397b124 读的。没有阻塞项——改动很小，描述里的推理经得起和源码对照，测试也是真能区分的，不是摆设。

我实际去核实（而不是照单接受）的点：

• 显式的 0 不会被 transport 吞掉。 this.connectTimeoutMs = options.connectTimeoutMs ?? 35_000 是 nullish 判断而非 falsy 判断，所以守卫传的 0 不会被打回 35 秒默认值。undefined 那一支也没问题：根 tsconfig 开了 strict 但没开 exactOptionalPropertyTypes，因此 connectTimeoutMs?: number 接受显式 undefined。
• 这个字段只有两个消费者（profiles() 与 connectWithinDeadline()，都是 deadline 运算）。requestTimeoutMs 没动，所以已连接会话的行为完全不变。
• 0 预算去掉的是轮询，不是那次检查。 profiles() 用的是 Date.now() >= deadline，所以返回 [] 之前仍会做一次 discovery——构造与调用之间才发布的 endpoint 依然能被发现。connectWithinDeadline() 是 do…while，所以仍会尝试一次，最终抛出的也仍是带 Web Store 文案的那条错误。这正是让 fix(browser-use): report Windows as unsupported instead of advising an install #13675 的 disconnectedMessage(platform) 分支在生产中仍然可达的原因；我拉了那个 PR 的 diff，组合性论证成立（文件零重叠，且被重写的那条 throw 正是本路径会落到的那条）。
• 守卫覆盖到了「付两次」的那条路径。 createBrowserSdkContext() → createBrowserBackend()，所以 bundled skill 的具名 profile 流程（按其 SKILL.md：先 browsers.list() 再 browsers.get(id)）由同一处改动覆盖，不需要在调用点再补一刀。
• 测试钉住了四个象限，并且守卫一旦放宽就会变红。 这是我原以为会薄弱的地方，结果不是：在 fake timers 下，如果被错误地套用 0 预算，connectHost 自己的 setTimeout(…, Math.max(1, deadline - Date.now())) 就是一个 1ms 定时器，会在 advanceTimersByTimeAsync(1_000) 内触发，于是三个 "still waits out the budget" 钉子会 settle 并失败——它们不是空过。把守卫改成只看平台，或者把 QWEN_BROWSER_USE_DISCOVERY_DIR 从 managed 里去掉，都会有测试变红。vi.hoisted 的 discovery mock 正是 AGENTS.md 要求的写法，也让测试不落到 runner 的文件系统上（不会触发 prepareDiscoveryDirectory 的 mkdir）。从静态推演看，两个 fail-fast 断言在未打补丁的源码上不可能通过（settledAfterMs 保持 NaN，而 NaN <= 1000 为假），这与描述里的 before 输出一致——那份输出是作者提供的，我没有重跑。

非阻塞项，两点在 Stage 1 都提过：

1. 剩余的情形是：在不可注册的平台上，默认 discovery 目录里出现一条存活记录。安装器之下的那层栈是 win32-aware 的，所以手写注册表项就能在我们的安装器从未运行时产生这样一条记录；在 0 预算下，这种配置仍能列出 profile，但 hello 握手只有 1ms，于是从「能连上」变成「连不上」。设计文档本来就不支持这种配置，fix(browser-use): report Windows as unsupported instead of advising an install #13675 也正要把它报成不支持，所以不需要改代码——但常量上方的注释现在写的是 "provably nothing to wait for"，而那正是这个说法会悄悄不成立的唯一位置。
2. hasManagedEndpointOverride() 与 supportsNativeHostRegistration() 各自只被调用一次，且相隔两行。直接写成 const managed = … / const registrable = … 放在既有注释下面，含义不变而间接层更少，这也正是 AGENTS.md「不为单次使用的代码做抽象」所指的方向。不过这两个名字确实记录了平台清单，所以属于取舍，不是缺陷。

测试证据

无人值守的 CI 运行——我没有构建、运行或 checkout 这个 PR 的任何东西。下面是该 PR 自己的 CI（针对被审查 commit 通过 API 取得）加上上述静态核实。

未验证： 真实 Windows 主机上的任何行为。没有 lane 能见证它——ci.yml 里 test_windows 与 test_macos 只在 merge_group / schedule / workflow_dispatch 下运行（我在文件里确认过，这里两者也都报 skipped），而且这个缺陷在 Linux / macOS 上根本不会发生。合并队列会在 Windows runner 上跑同一批平台打桩测试，但那至多是很弱的见证：测试打桩了 process.platform，真实主机额外带来的只有 chromeDiscoveryDirectory() / profileSocketPath() / verifySocketPeerPath() 的 win32 分支。

CI 表格见上方（由 finalize 工作流在 CI 跑完后原地更新）。该 commit 上共 26 个 check-run，撰写时 0 失败。关键的 Test (ubuntu-latest, Node 22.x)（它会 install 并触发 workspace 的 prepare 构建，然后跑包含 packages/browser-use/src/runtime.test.ts 的测试套件）当时仍在进行中，所以单元测试结果还没出来；review-pr 与 triage 属于机器人编排，不是 PR 的 CI。Lint & Static 已绿，而该 lane 在 bundle-closure 与 subpath-export 步骤之前会构建 workspace，所以这条路径上的编译错误多半已经会在那里暴露。目前没有红项，因此没有失败日志可引。

有一个 CI 无法判定的说法，可以用沙箱验证来收口：@qwen-code /verify——单元 lane 见证了打桩平台上的 fail-fast，但没有任何东西覆盖上面第 1 点的剩余情形，即在不可注册平台上「被发现的 endpoint 是否还能连上」（connectHost() 现在拿到的是 1ms 的 hello 预算，而不是约 35 秒）。对着 base 构建做一次 /verify A/B 就能钉住这个行为；作者有写权限，不需要 sponsored run。/tmux 在这里不合适——这个 diff 没有任何 TUI 面。

— Qwen Code · qwen3.8-max-2026-09-02

_{Reviewed at 1397b1249487b34403e89d40a960cb1cc9caa485 · re-run with @qwen-code /triage}

[qwen-code-review-bot]

Confidence: 4/5 — clean at every stage; what keeps it from a 5 is two cosmetic nits and one residual case in an unsupported configuration, none of which change behaviour for anything the installer can produce.

Before reading the diff I wrote down what I'd do from the issue alone: the decision belongs in the backend factory, because that's the only place that knows both that registration was skipped and whether a managed override publishes an endpoint; express it as a near-zero connect budget on the transport rather than an early throw; and key it on the same condition registration uses, not on the platform alone. That's what this PR does. The alternatives I weighed are worse and the description argues two of them better than I would have — throwing from the factory would strand #13675's reworded win32 message and change the observable failure mode, and teaching the transport the installer's platform policy would be the wrong layer (!explicitSocketPath really isn't equivalent, since it ignores the discovery dir). Shortening the 35s default globally would be the wrong fix outright: that budget exists because Chrome relaunches its Host on a 30s alarm, so an empty snapshot on a registrable platform is not evidence that no browser exists.

It solves something users actually hit, not a hypothetical: 35s per wait, roughly 70s on the named-profile path, and again on every retry because the bundled skill clears its runtime singleton on failure. The linked issue is a triaged P2 with measurements, split out of the parent report deliberately.

The code is straightforward and I'd thank rather than curse it in six months — one constant, two predicates, one ternary, 41 production lines. Every edit is in service of the stated goal: no drive-by refactor, no formatting churn, and the extraction is the minimum needed to keep the install gate and the timeout gate from drifting apart. The test additions are the part that impressed me most; I went in expecting pins that pass either way and found four cases that fail if the guard is broadened, because a wrongly-applied 0 budget turns connectHost's own hello timer into a 1ms fake timer that settles inside the assertion window.

Am I approving because I ran out of reasons to say no? The two I have left are the ones from Stage 2: the predicate wrappers are each called once, two lines apart, where inline consts would carry the same meaning with less indirection; and the comment above the constant says "provably nothing to wait for", which holds for every configuration our installer can produce but not for a hand-registered host publishing into the default discovery dir on such a platform. Neither is worth holding the PR for — the first is taste, the second is a comment clause in a configuration the design doc already declares unsupported and #13675 is about to report as such.

One note for whoever merges, not a concern about the change: this author also has #13675 open in the same disconnect path. I verified the non-overlap claim from the diffs rather than taking it (zero shared files), and this PR deliberately routes through connectWithinDeadline() so both merge orders compose. Sequencing is still a human call, but nothing here forces an order.

Approval is deferred, not withheld. Qwen Code CI — specifically Test (ubuntu-latest, Node 22.x), the lane that runs the new runtime.test.ts cases — was still in progress when I wrote this, and I won't attest to a result that doesn't exist yet. Everything else on this commit is green or skipped-by-design, with 0 failures. Approval lands automatically once CI is green on 1397b1249487b34403e89d40a960cb1cc9caa485, pinned to that commit; if anything goes red or the head moves first, it won't.

中文说明

Confidence: 4/5 —— 各阶段都干净；没到 5 分是因为两个纯观感的小问题，以及一个只存在于「不受支持配置」里的剩余情形，二者都不会改变安装器能产出的任何配置下的行为。

在读 diff 之前，我先按 issue 写下了自己的做法：这个判断应该放在 backend 工厂里，因为只有那里同时知道「注册被跳过」和「是否有托管 override 在发布 endpoint」；用给 transport 传一个接近 0 的连接预算来表达，而不是提前抛错；并且守卫条件要与注册所用的条件一致，而不是只看平台。这个 PR 做的正是这件事。我权衡过的其他方案都更差，而且其中两个方案作者论证得比我会写的更好——从工厂里抛错会让 #13675 重写的 win32 文案变成死代码，还会改变可观测的失败形态；把安装器的平台策略教给 transport 则是放错了层（!explicitSocketPath 确实不等价，它忽略了 discovery 目录）。至于把 35 秒默认值全局调小，那根本就是错的修法：这个预算存在的原因是 Chrome 会以 30 秒闹钟重启它的 Host，所以在可注册平台上，一次空快照并不能证明没有浏览器存在。

它解决的是用户真会碰到的问题，不是假想：每次等待 35 秒，具名 profile 路径约 70 秒，而且因为 bundled skill 在失败时会清掉 runtime 单例，每次重试都要再付一遍。关联 issue 是已分诊的 P2，带实测数据，并且是刻意从父报告里拆出来的。

代码很直白，六个月后我会感谢而不是咒骂它——一个常量、两个谓词、一个三元表达式，41 行生产代码。每处改动都服务于既定目标：没有顺手重构，没有格式化噪音，而那次抽取正是让「安装门」与「超时门」不会彼此漂移所需的最小改动。测试部分最让我意外：我原以为会看到那种改与不改都过的钉子，结果是四个一旦守卫被放宽就会失败的用例——因为错误地套用 0 预算会让 connectHost 自己的 hello 定时器变成 1ms 的 fake timer，在断言窗口内就 settle。

我是不是因为说不出反对理由才 approve？我剩下的两条正是 Stage 2 里那两条：两个谓词各自只被调用一次、相隔两行，写成内联常量含义相同而间接层更少；常量上方的注释写着 "provably nothing to wait for"，这对我们的安装器能产出的所有配置都成立，但对「在这类平台上手写注册、把记录发布到默认 discovery 目录」的 Host 不成立。两条都不值得卡住这个 PR——第一条是口味问题，第二条是设计文档已经声明不支持、#13675 也正要报成不支持的配置里的一句注释措辞。

给合并者的一条提示，与改动本身无关：同一位作者在同一个断连路径上还有 #13675 处于 open。我是从两边 diff 核实了「零重叠」的说法，而不是照单接受（确实没有共享文件），并且本 PR 刻意走 connectWithinDeadline()，所以两种合并顺序都能组合。排序仍然是人的判断，但这里没有任何东西强制某个顺序。

approval 是延后，不是拒绝。 我写这段时 Qwen Code CI 仍在进行中——具体是 Test (ubuntu-latest, Node 22.x)，也就是运行新增 runtime.test.ts 用例的那条 lane——而我不会为一个还不存在的结果背书。该 commit 上其余检查要么已绿，要么是按设计跳过，0 失败。CI 在 1397b1249487b34403e89d40a960cb1cc9caa485 上跑绿后，approval 会自动落到那个 commit 上；如果中途有红项或 head 发生移动，则不会落。

— Qwen Code · qwen3.8-max-2026-09-02

_{Reviewed at 1397b1249487b34403e89d40a960cb1cc9caa485 · re-run with @qwen-code /triage}

[qwen-code-review-bot]

LGTM, looks ready to ship — CI landed green after the review. ✅

[qwen-code-review-bot]

Reviewed — no blockers. Suggestions are inline.

Test Plan (not a blocker): src/runtime.test.ts — no such file or directory; src/bridge/transport/chrome-extension-transport.test.ts — no such file or directory; src/runtime.ts — no such file or directory.

中文说明

已审查——无阻断问题。 建议见行内评论。

Test Plan（非阻断）：src/runtime.test.ts — no such file or directory; src/bridge/transport/chrome-extension-transport.test.ts — no such file or directory; src/runtime.ts — no such file or directory。

— qwen3.8-max via Qwen Code /review (v0.25.0)

[qwen-code-review-bot]

Partially reviewed — gaps disclosed. Suggestions are inline.

Not explored to full depth (tool budget reached): "agent 6a": none — no check was cut short..

Not reviewed: reverse audit — stopped before round 1 by the review time budget.

Test Plan (not a blocker): src/runtime.test.ts — no such file or directory; src/bridge/transport/chrome-extension-transport.test.ts — no such file or directory; src/runtime.ts — no such file or directory; Tests 14 passed — this review observed 591, 2633, 39964, 35646, 1028, 2172, 609, 11087 passed; 12 passed — this review observed 591, 2633, 39964, 35646, 1028, 2172, 609, 11087 passed; and 3 more.

中文说明

仅完成部分审查，审查缺口已披露。 建议见行内评论。

未探索到全部深度（达到工具调用预算）："agent 6a"：none — no check was cut short.。

未审查：反向审计——评审时间预算不足，未能开始第 1 轮。

Test Plan（非阻断）：src/runtime.test.ts — no such file or directory; src/bridge/transport/chrome-extension-transport.test.ts — no such file or directory; src/runtime.ts — no such file or directory; Tests 14 passed — this review observed 591, 2633, 39964, 35646, 1028, 2172, 609, 11087 passed; 12 passed — this review observed 591, 2633, 39964, 35646, 1028, 2172, 609, 11087 passed; and 3 more。

— qwen3.8-max via Qwen Code /review (v0.25.0)

[qwen-code-review-bot]

Reviewed — no blockers. Suggestions are inline.

Test Plan (not a blocker): src/runtime.test.ts — no such file or directory; src/bridge/transport/chrome-extension-transport.test.ts — no such file or directory; src/runtime.ts — no such file or directory.

Convergence: round 3 posted 1 inline comment(s), 1 of them reported for the first time; the previous round posted 1 (1 new). Findings keep coming back to the same files: docs/design/browser-use.md (findings in round 1; 1 more now). The rate of new findings is not falling. A cluster that keeps producing siblings usually means the fixes are treating instances of a shared root cause — triaging that cause before the next round, or splitting an independent cluster into its own pull request, tends to end the loop faster than fixing them one at a time. Batching the remaining fixes and verifying them before the next push, or dropping this PR's reviews to --severity-floor critical, keeps the loop from re-deriving the same set. No Critical finding is open on this round, so merging and moving the remaining Suggestion threads to a follow-up issue is available as an ending — a merged pull request cannot diverge further. (Observation only — nothing was withheld from this review because of this observation.)

中文说明

已审查——无阻断问题。 建议见行内评论。

Test Plan（非阻断）：src/runtime.test.ts — no such file or directory; src/bridge/transport/chrome-extension-transport.test.ts — no such file or directory; src/runtime.ts — no such file or directory。

收敛情况：第 3 轮发布了 1 条行内评论，其中 1 条是首次提出；上一轮发布了 1 条（其中 1 条首次提出）。发现反复回到同一批文件：docs/design/browser-use.md（第 1 轮已出过发现，本轮又有 1 条）。新发现的产出速度没有下降。一个不断再生兄弟发现的簇，通常意味着逐条修复只在处理同一根因的实例——先定位并处理该根因，或把独立的簇拆成单独的 PR，通常比逐条修复更快结束循环。把剩余修复攒成一批、验证后再推送，或将本 PR 的评审降到 --severity-floor critical，可以避免循环反复推导同一组发现。本轮没有未决的 Critical，因此"合入后把剩余 Suggestion 线程转到后续 issue"是一个可选的结束方式——已合入的 PR 不会继续发散。（仅为观察——本轮评审未因此扣留任何内容。）

— qwen3.8-max via Qwen Code /review (v0.25.0)

[qwen-code-review-bot]

No issues found. LGTM! ✅

Test Plan (not a blocker): src/runtime.test.ts — no such file or directory; src/bridge/transport/chrome-extension-transport.test.ts — no such file or directory; src/runtime.ts — no such file or directory.

中文说明

未发现问题。LGTM！✅

Test Plan（非阻断）：src/runtime.test.ts — no such file or directory; src/bridge/transport/chrome-extension-transport.test.ts — no such file or directory; src/runtime.ts — no such file or directory。

— qwen3.8-max via Qwen Code /review (v0.25.0)

[chiga0]

Tier: Standard (platform-gated fast-fail, +170/-12, 5 files).

No blockers. LGTM ✅

What I checked

1. connectTimeoutMs is a real field on ChromeExtensionTransportOptions (line 51 of bridge/transport/chrome-extension-transport.ts). Default is 35,000 ms; passing 0 sets the connect deadline to Date.now() + 0, so the transport fails immediately when no host will register. The two deadline sites (lines 213, 278) use it directly — there is no secondary guard that would override 0.

2. hasManagedEndpointOverride() correctly handles both QWEN_BROWSER_USE_SOCKET_PATH and QWEN_BROWSER_USE_DISCOVERY_DIR, with .trim() guarding whitespace-only values. Either env var alone is sufficient to skip the fast-fail — correct, because either is sufficient for a managed endpoint.

3. NATIVE_HOST_SUPPORTED_PLATFORMS export creates a single source of truth used by the installer check, describeChromeProfiles, and the new runtime predicate — no silent divergence.

4. Test coverage: 4 new tests exercise all four branches (fast-fail on win32 + no env, quick rejection on win32 + no env, managed override preserves wait, linux native path preserves wait). The "Before" output in the PR description shows expected NaN to be ≤ 1000 (never settled); the "After" output shows it settling within 1000 ms — conclusive evidence that connectTimeoutMs: 0 is wired end-to-end.

Not reviewed: the existing behavior of describeChromeProfiles and resolveOptions on darwin/linux (unchanged, not in diff scope).

Reviewed with AI assistance.

[qwen-code-dev-bot]

Verified at head 748147b.

Gate 1. Head SHA fixed as above; every conclusion targets that SHA only.

Gate 2. All four review threads are resolved, and no historical Critical or necessary Suggestion remains outstanding.

Gate 3. Required CI is 29 of 29 complete and green, with nothing pending, cancelled, or failing. For transparency, the main ruleset for this repository configures no required_status_checks rule, so I judged the substantive lanes and excluded only review-pr, route, delay-automatic-review and fallback-comment, which are the reviewer bot and housekeeping routing.

Gate 4. No new Critical. The fix rests on one invariant and I checked it instead of assuming it: a connectTimeoutMs of 0 has to survive construction, and it does, because ChromeExtensionTransport assigns options.connectTimeoutMs ?? 35_000 with nullish coalescing at line 86, so 0 is preserved where a logical or would have silently restored the 35 second default and turned the fast fail into a no-op. Both deadline computations at 213 and 278 then read that field, so the poll exits at once rather than waiting for an endpoint that provably cannot appear, since registration is impossible on the platform and no managed endpoint override is set. NATIVE_HOST_SUPPORTED_PLATFORMS is now the single source of truth at all three sites, describeChromeProfiles, resolveOptions and the runtime registrability test, so the fast fail and the installer support list cannot drift, and the comment records why win32 is absent and what adding it would require. hasManagedEndpointOverride preserves the previous environment semantics exactly, and both the managed and the registrable cases pass undefined, leaving the existing 35 second behavior untouched. The only changed behavior is the intended one.

Gate 5. Head SHA, PR state, required checks, and unresolved thread count were re read atomically immediately before submitting this review.

[qqqys]

APPROVE at 748147b07274e94b22595fe3223227f20c82edd4. No historical blocking issue exists on this PR, and my own Critical-only scan of the full diff found nothing that would block merging.

Historical review

Nothing to re-verify. Across four reviewer rounds every filed finding was a Suggestion — no Critical, and no CHANGES_REQUESTED carrying a correctness objection. The one DISMISSED review on this PR is an approval that CI landed green after, not a withdrawn blocker. All review threads are resolved.

What I verified in the source at this head

The fix is small, but its correctness rests on a 0 timeout surviving three places that could each silently turn it back into the 35s default or skip discovery entirely. I checked all three:

• 0 is not folded into the default. ChromeExtensionTransport reads the option with options.connectTimeoutMs ?? 35_000 (bridge/transport/chrome-extension-transport.ts:86), not ||, so UNREGISTERABLE_HOST_CONNECT_TIMEOUT_MS = 0 is preserved rather than read as "unset".
• The fast path still performs one honest discovery pass. profiles() uses for (;;) and calls discoverChromeProfiles() before the Date.now() >= deadline check (:213-222), and connectWithinDeadline() is a do { … } while (:278-297). With a zero deadline each therefore runs exactly once instead of never, so an endpoint that is already published is still found and the incompatible-version path still throws versionMismatch() when profiles.length > 0. Only the wait for a late-arriving endpoint is removed, which is what #13692 asks for.
• No zero or negative budget is handed downstream. connectHost(…, Math.max(1, deadline - Date.now()), …) clamps the remaining budget, so the expired deadline cannot produce a 0ms connect call.

The guard's own preconditions hold. hasManagedEndpointOverride() and supportsNativeHostRegistration() reproduce the previous inline condition exactly — !SOCKET_PATH?.trim() && !DISCOVERY_DIR?.trim() && (darwin || linux) is now !managed && registrable — so which platforms install a Host is unchanged, and only the connect budget differs. Deriving the platform list from the exported NATIVE_HOST_SUPPORTED_PLATFORMS rather than restating 'darwin'/'linux' also removes the drift the two resolveOptions/describeChromeProfiles sites previously allowed; both now read the same constant (native-host-installer.ts:291, :371).

The new tests pin all four branches that matter: fast browsers.list → [], fast browsers.get → BROWSER_DISCONNECTED, a managed override on such a platform still waiting out the budget, and a registrable platform still waiting out the budget. Each asserts on elapsed time rather than only on the result, which is what makes the "at once" claim testable.

CI

15 checks pass at this head, 56 are skipped, and nothing fails or is pending. No failure is attributable to this PR.

[qwen-code-review-bot]

Released in v0.25.1.