@anweat/dsh-browser

dsh plugin --profile web add @anweat/dsh-browser

dsh-browser

本地整合候选的修复、工具清单与安全边界见 [AUDIT.md](AUDIT.md)。allowedDomains 只限制认证状态装载，不是网络防火墙或 Agent 隔离边界。

自包含的浏览器运行时插件 for DeepSeek Harness（DSH）。

把 Playwright / Patchright（可选 Chromium 驱动） 作为插件自身的 npm 依赖，对外提供一个 browser 服务 + 一组交互式浏览器工具。dsh-web-search-pro 通过 inject: ['browser'] 注入该服务，驱动它的浏览器 / OpenCLI 后端。

浏览器本身不随插件下载：装了 Google Chrome 或 Microsoft Edge 就直接用（自动检测，不用配置）；都没有时才需要装 Playwright 的 Chromium（runtime.install，下载约 190 MB）。OpenCLI 是可选的、需要单独安装（npm i -g @jackwener/opencli）：只有 opencli.* 动作和 Web Search Pro 的 browser-opencli 后端用到它，不装也不影响其他浏览器工具，也不会让 dsh plugin add 报失败（见「第一次使用」与「升级到 0.2.2」）。

兼容与发布通道

插件发布通道 · DSH 基线 · 兼容承诺

0.1.12 及更早的维护版本 · dsh-v0.1.1-rc.2 至 dsh-v0.1.2-rc.1 · 旧基线；不与新插件混装

0.1.15 · dsh-v0.1.7-rc.2 · 精确锁定该宿主版本；组合安装、真实 Web profile 与设置持久化已验证

0.1.17 · dsh-v0.1.7-rc.2 ~ dsh-v0.2.0-rc.2 · peer 收口为「实测过的两条线」（上界 <0.2.1-0）；在 0.2.0-rc.2 上完成 typecheck、构建、52 项测试与真实挂载验证；补充浏览器缓存路径配置说明，并新增 peer 双解析模式检查

0.2.0-rc.1（预发布，历史记录） · dsh-v0.1.7-rc.2 ~ dsh-v0.2.0-rc.2 · 破坏性变更：30 个 browser_* 工具改为 browser_index / browser_call 两个入口加动作目录（常驻约 325 token，原约 8.8k）；随包提供 dsh-browser skill；recipe v2、资产版本与激活保护、结构化观察、探索记录生成草稿、提示文本可配置。并入按 session 隔离浏览器状态（#36）与 dialog 竞态修复（#30）。在 0.2.0-rc.2 上完成 325 项测试、64 项真实浏览器 e2e 与真实 Web profile 验证

0.2.0 · dsh-v0.2.0-rc.2 · 第一个面向 DSH 桌面版 0.2.0 线的正式版，也是后续开发的基底。只支持 dsh-v0.2.0-rc.2 这一条线（peer >=0.2.0-rc.2 <0.2.1-0）：去掉为更旧宿主保留的兼容分支（settings.register 的 live scope 回退等），并去掉对 settings 服务的必需依赖（只声明 inject: ['tools']，没有 Settings 服务的组合里也能启动）；不改工具、动作、schema、文本与审批规则。在 0.2.0-rc.2 上完成 327 项测试、64 项真实浏览器 e2e 与 peer 双解析模式检查。旧宿主（0.1.7 线，dsh-v0.1.7-rc.2）继续使用 0.1.17

0.2.1 · dsh-v0.2.0-rc.2（不变） · 相对 0.2.0 的补丁版，DSH 基线与 peer 范围（>=0.2.0-rc.2 <0.2.1-0）不变，只含两项：(1) 参数无效的调用不再先弹审批：审批钩子先判断动作是否被当前 automationMode 禁用（禁用仍直接拒绝），再用与 runAction 相同的校验检查参数，无效则不询问，执行层再校验一次并返回带精简 schema 的 INVALID_ARGS，不执行任何页面动作；参数有效时的审批规则与理由不变。(2) “探索转草稿”（draft_from_journal）的指导文本补充。不改动作、参数 schema 与审批规则。在 0.2.0-rc.2 上完成 337 项测试与 66 项真实浏览器 e2e

0.2.2 · dsh-v0.2.0-rc.2，dsh-v0.2.1-rc.2 / rc.3 / rc.4 · 同时支持两条线（受管 peer >=0.2.0-rc.2 <0.2.1-0 \ · \ · >=0.2.1-rc.2 <0.2.2-0，Cordis peer ~4.0.4，devDependencies 锁在 0.2.1-rc.3，schemastery 3.18.5）。源码不为任何一个宿主版本改动：在真实安装的 0.2.0-rc.2、0.2.1-rc.3、0.2.1-rc.4 宿主上都完成了干净安装、Web 设置卡片渲染与保存、skill 注册、资产 RPC、tools/pre-execute 审批钩子的验证（见 docs/validation/2026-10-28-compat-dist.md）。安装行为变化：OpenCLI 不再是依赖（它的安装脚本会让 pnpm 11 的 dsh plugin add 失败），Playwright 的 Chromium 缺失时自动改用系统 Chrome / Edge（见「第一次使用」）。功能面新增 context 创建期选项、下载落盘与策略覆盖层（见「升级到 0.2.2」）。0.2.0 线宿主此前只能用 0.2.1，现在也可以装 0.2.2

0.2.2 的范围是两段：>=0.2.0-rc.2 <0.2.1-0 || >=0.2.1-rc.2 <0.2.2-0，各对应一条实测过的线（0.2.0 线只有 0.2.0-rc.2，

0.2.1 线是 rc.2 / rc.3 / rc.4）。0.2.0-rc.1、0.2.1-alpha.*、0.2.1-rc.1 与 0.2.2 及以上（含它的预发布）一律拒绝。

Cordis peer 是 ~4.0.4：0.2.0-rc.2 宿主声明 ~4.0.4，0.2.1-rc.2 起声明 ~4.0.5，两个小版本在本插件用到的契约上没有差别

（插件只把 Cordis 当类型用；在把 Cordis 固定成 4.0.4 的 0.2.0-rc.2 宿主上也验证了加载与工具注册）。schemastery 3.18.5 仍被 >=3.18.2 <4 覆盖。

把 0.2.0 线放回范围的依据：插件在 0.2.0-rc.2 上用到的宿主接口（tools 注册与 tools/pre-execute 钩子、Config 的 .volatile() 与

settings/mutate 原子保存、connection.rpc.handle + webServer、skills.registerProvider、客户端模块表里的 primitives / slots /

plugin-manager）与 0.2.1 线逐项一致，真实宿主上的差别只有 Cordis 小版本。test:peers 把四个基线并入受支持矩阵，并断言被拒绝的版本。

0.1.17 把 DSH 运行时依赖由精确锁定改为范围声明（^0.1.7-rc.2 || >=0.2.0-rc.1 <0.2.1-0），

使同一份包可装在 0.1.7-rc.2 与 0.2.0-rc.2 两代宿主上。0.2.0-rc.1 起的新功能（动作体系、skill、recipe v2、

资产版本、提示文本配置等）只在 0.2.0-rc.2 上验证过，没有在 0.1.7-rc.2 上跑过，所以 0.2.0 把范围收成**只覆盖

0.2.0-rc.2 这条线**：>=0.2.0-rc.2 <0.2.1-0，正式版 0.2.0 起即采用这个范围。0.1.17 的范围不变，旧宿主继续用它。

这个写法同时满足两种解析，缺一不可：

• 宿主的组装期校验用的是 semver.satisfies(host, range, { includePrerelease: true })，所以「单范围能不能过宿主」不是关键。

真正决定装机成败的是 npm/pnpm 的默认 semver：预发布版本只有在某个比较符自带同号（同 major.minor.patch）预发布时才被判为满足。

于是一段式的 >=0.2.0-rc.2 <0.2.2-0 过得了宿主校验，却会让 dsh plugin add 报 ERESOLVE（下界 tuple 是 0.2.0，接不住 0.2.1-rc.2）；

所以写成两段，每一段的下界（>=0.2.0-rc.2、>=0.2.1-rc.2）都自带该线的同号预发布，是承重的，必须保留。

• 上界是 <0.2.2-0 而不是 <0.2.2：后者放行 0.2.2-alpha.1 这类 0.2.2 的预发布。收口后，若 0.2.2 真出现破坏，

会在组装期直接报 is incompatible with dsh 0.2.2 并点名，而不是拖到用户机器上变成运行期怪错

（0.1.5 → 0.1.7 曾一次性打断所有按 0.1.5-alpha.1 构建的插件）。

• 范围只表示「测过哪些」，不等于承诺不破坏；真正的防线是每换一个 DSH 版本重跑一遍这套验证。

pnpm run test:peers（已并入 pnpm verify）用两种解析模式逐个断言受管 peer：0.2.0-rc.2、0.2.1-rc.2 / rc.3 / rc.4 必须通过，

0.1.7-rc.2、0.2.0-rc.1、0.2.1-alpha.*、0.2.1-rc.1、0.2.2-alpha.1、0.2.2 必须被拒绝；并自带 --selftest 已知行为自校验。

0.1.15 使用 DSH 新客户端分包：状态存储来自

dsh-client-store，设置契约来自 dsh-client-ui-settings，客户端 Context

来自 Cordis。npm 上 0.1.15-alpha.2 仍声明旧版 DSH peer，不能与本版混用。

设置的读取不再对宿主版本做适配：Host 半边直接使用 Loader 传给 apply 的条目配置（设置页由条目的 Config schema 派生，

条目 id 为 browser），浏览器设置卡片使用 ConfigForm/ctx.configForms，devDependencies 锁定 0.2.1-rc.3（类型与单测按这一版；0.2.0-rc.2 与 0.2.1-rc.4 靠真实宿主验证，不在 devDependencies 里）。

可编辑字段都是 .volatile()：保存后新值写入运行中的引用，但浏览器进程、工具暴露与审批规则在启动时一次读取，

所以保存后仍需重启 profile 才生效（只有提示文本覆盖里的目录、错误提示等按调用实时读取，见「自定义提示文本」）。

插件只声明 inject: ['tools']，不依赖宿主的 settings 服务：Cordis 4.0.5 把声明了的 inject 一律当作必需，若声明 settings，

在没有该服务的组合（如 sdk-minimal，或关了 settings 行的 profile）里插件会一直挂起。插件的 Host 半边从不读取 ctx.settings，

配置来自 Loader 条目；没有 Settings 服务时按 Config 默认值运行，设置卡片只是不显示（客户端只在宿主提供 browser 命名空间时才挂载它）。

安装

# 默认安装（新的 browser_index / browser_call 工具体系，面向 dsh-v0.2.0-rc.2 与 dsh-v0.2.1-rc.2 ~ rc.4 宿主）：
dsh plugin --profile web add @anweat/dsh-browser@0.2.2
# 宿主仍是 0.1.7 线（dsh-v0.1.7-rc.2）时，固定安装 0.1.17（旧的 browser_* 工具体系）：
dsh plugin --profile web add @anweat/dsh-browser@0.1.17
# 或本地目录 / tarball：
dsh plugin --profile web add ./dsh-browser
# 重启（web profile 关闭了 HMR）：
dsh --profile web

0.2.0 与 0.2.1 只支持 dsh-v0.2.0-rc.2（peer >=0.2.0-rc.2 <0.2.1-0），0.2.2 支持 dsh-v0.2.0-rc.2 与

dsh-v0.2.1-rc.2 ~ rc.4（peer >=0.2.0-rc.2 <0.2.1-0 || >=0.2.1-rc.2 <0.2.2-0）；范

…(truncated)