Summary
@wxg-prc-cpg/browser-skill-dsh-plugin@0.3.1 registers nothing on the current DSH Desktop release: no browser_* tools, no browser-skill skill — silently, with no error logged anywhere. The same symptom occurs with 0.3.0, so this is not a 0.3.1 regression.
The most likely cause is an SDK/peer mismatch: the plugin declares @deepseek-ai/dsh-tools@^0.1.5-rc.3 (and dsh-llm, dsh-attachment, … at ^0.1.5-rc.3) plus @deepseek-ai/cordis@^4.0.2, while the newest DSH Desktop bundles DeepSeek Harness v0.1.5-rc.2 — and ^0.1.5-rc.3 does not match rc.2. Also note there is no v0.1.5-rc.3 release upstream at all (upstream went 0.1.5-rc.1 → 0.1.5-rc.2 → 0.1.6-alpha.x → 0.1.7-rc.1).
Environment
- DSH Desktop 2.0.13 — the latest release (2026-09-19); its release notes state it keeps DeepSeek Harness at
v0.1.5-rc.2. Windows 11.
- Bundled host CLI:
0.1.5-rc.2
- Plugin
@wxg-prc-cpg/browser-skill-dsh-plugin 0.3.1 (installed with dsh plugin --profile desktop add; also installed into the web profile)
- bsk CLI 0.3.1 + extension 0.3.1 — both work perfectly:
bsk status → daemon ready, browsers connected 1, and navigate / observe verified end-to-end on the same machine.
Symptoms
After installing the plugin and restarting DSH:
browser_* tools absent. Verified with the Cordis Tool Inspect provider (Tool.listTools): 102 tools total, 0 matching browser_*.browser-skill skill absent from the skill catalog — in the existing session and in a brand-new agent/session (which fires agent/session-start).- No diagnostics at all: no plugin log directory is created, nothing relevant in the desktop log.
What we ruled out
- Composition is correct.
dsh --profile desktop --dump-config shows the row with the right package name and our config merged:
# == @wxg-prc-cpg/browser-skill-dsh-plugin, patched by ...cordis.patch.yml
- id: browserskill
name: '@wxg-prc-cpg/browser-skill-dsh-plugin'
config:
bskPath: C:\Users\<user>\.local\bin\bsk.exe
lazyTools: false
- The module itself is fine. Importing
lib/index.mjs under plain Node succeeds, and calling apply(mockCtx) runs to completion — it even registers the skill in that harness. So the plugin's own logic is not broken.
apply() does start inside the real host. ~/.bsk/dsh-starts/<hash>/<pid>-<uuid> — created by DiskStartJournal inside apply() (around line 5473) — exists on disk. But nothing after that point takes effect.lazyTools: false was set explicitly, so eager registration was requested — still nothing.
Put together, the failure looks like: apply() begins, then throws (or is aborted) around the SDK-touching calls, and the row is dropped silently.
Impact
Users on the latest DSH Desktop cannot use this plugin at all — and they get no feedback, so it looks like nothing happened. For a plugin advertised as the DSH integration path, this is the worst failure mode.
Suggestions
- Support
0.1.5-rc.2 (peer ^0.1.5-rc.2) — that is what every current DSH Desktop user actually has; or
- If a newer harness is genuinely required, state the minimum harness version in the README / plugin page, and fail loudly (log or throw with a clear message) instead of registering nothing;
- Consider making the skill registration non-fatal (wrap it in try/catch) so SDK drift cannot take down the whole tool suite;
- If
0.1.5-rc.3 is an internal/preview SDK, please ship builds against the released one.
Reference: driving the bsk CLI from an agent shell (session start → navigate → observe → stop) works end-to-end on the same machine, so the browser side is healthy — this is purely a DSH-plugin loading issue.
Related but different: #269 (lazy reveal not restored after a plugin reload) — there the tools had registered at least once; here nothing registers at all.
中文摘要
@wxg-prc-cpg/browser-skill-dsh-plugin@0.3.1 在最新版 DSH Desktop（2.0.13，内置 harness v0.1.5-rc.2）上什么都不注册：既没有 browser_* 工具、也没有 browser-skill 技能，而且完全静默、无任何日志（0.3.0 同样，非 0.3.1 回归）。
最可能的原因是 SDK 版本不匹配：插件声明 @deepseek-ai/dsh-tools@^0.1.5-rc.3 等 peer 与 @deepseek-ai/cordis@^4.0.2，而最新桌面端只捆绑 v0.1.5-rc.2，^0.1.5-rc.3 不匹配 rc.2；而且上游根本没有发布过 v0.1.5-rc.3（发布序列是 rc.1 → rc.2 → 0.1.6-alpha → 0.1.7-rc.1）。
已排除：① 组成树正确（行、name、config 都在）；② 模块在纯 Node 下可导入且 apply(mockCtx) 能跑通并注册技能；③ 宿主里 apply() 确实启动过（~/.bsk/dsh-starts/... 的 journal 文件是证据），但之后全部无效。
建议：支持 rc.2；若确实需要更新的 harness，请在文档里写明最低版本并显式报错而不是静默不注册；把技能注册改为非致命（try/catch），避免 SDK 漂移拖垮整个工具集。注：bsk CLI 路线在同机上已端到端验证可用，浏览器侧本身是好的。
Summary
@wxg-prc-cpg/browser-skill-dsh-plugin@0.3.1registers nothing on the current DSH Desktop release: nobrowser_*tools, nobrowser-skillskill — silently, with no error logged anywhere. The same symptom occurs with 0.3.0, so this is not a 0.3.1 regression.The most likely cause is an SDK/peer mismatch: the plugin declares
@deepseek-ai/dsh-tools@^0.1.5-rc.3(anddsh-llm,dsh-attachment, … at^0.1.5-rc.3) plus@deepseek-ai/cordis@^4.0.2, while the newest DSH Desktop bundles DeepSeek Harnessv0.1.5-rc.2— and^0.1.5-rc.3does not matchrc.2. Also note there is nov0.1.5-rc.3release upstream at all (upstream went0.1.5-rc.1→0.1.5-rc.2→0.1.6-alpha.x→0.1.7-rc.1).Environment
v0.1.5-rc.2. Windows 11.0.1.5-rc.2@wxg-prc-cpg/browser-skill-dsh-plugin0.3.1 (installed withdsh plugin --profile desktop add; also installed into thewebprofile)bsk status→daemon ready,browsers connected 1, andnavigate/observeverified end-to-end on the same machine.Symptoms
After installing the plugin and restarting DSH:
browser_*tools absent. Verified with the Cordis Tool Inspect provider (Tool.listTools): 102 tools total, 0 matchingbrowser_*.browser-skillskill absent from the skill catalog — in the existing session and in a brand-new agent/session (which firesagent/session-start).What we ruled out
dsh --profile desktop --dump-configshows the row with the right package name and our config merged:lib/index.mjsunder plain Node succeeds, and callingapply(mockCtx)runs to completion — it even registers the skill in that harness. So the plugin's own logic is not broken.apply()does start inside the real host.~/.bsk/dsh-starts/<hash>/<pid>-<uuid>— created byDiskStartJournalinsideapply()(around line 5473) — exists on disk. But nothing after that point takes effect.lazyTools: falsewas set explicitly, so eager registration was requested — still nothing.Put together, the failure looks like:
apply()begins, then throws (or is aborted) around the SDK-touching calls, and the row is dropped silently.Impact
Users on the latest DSH Desktop cannot use this plugin at all — and they get no feedback, so it looks like nothing happened. For a plugin advertised as the DSH integration path, this is the worst failure mode.
Suggestions
0.1.5-rc.2(peer^0.1.5-rc.2) — that is what every current DSH Desktop user actually has; or0.1.5-rc.3is an internal/preview SDK, please ship builds against the released one.Reference: driving the
bskCLI from an agent shell (session start→navigate→observe→stop) works end-to-end on the same machine, so the browser side is healthy — this is purely a DSH-plugin loading issue.Related but different: #269 (lazy reveal not restored after a plugin reload) — there the tools had registered at least once; here nothing registers at all.
中文摘要
@wxg-prc-cpg/browser-skill-dsh-plugin@0.3.1在最新版 DSH Desktop（2.0.13，内置 harness v0.1.5-rc.2）上什么都不注册：既没有browser_*工具、也没有browser-skill技能，而且完全静默、无任何日志（0.3.0 同样，非 0.3.1 回归）。最可能的原因是 SDK 版本不匹配：插件声明
@deepseek-ai/dsh-tools@^0.1.5-rc.3等 peer 与@deepseek-ai/cordis@^4.0.2，而最新桌面端只捆绑v0.1.5-rc.2，^0.1.5-rc.3不匹配 rc.2；而且上游根本没有发布过v0.1.5-rc.3（发布序列是 rc.1 → rc.2 → 0.1.6-alpha → 0.1.7-rc.1）。已排除：① 组成树正确（行、name、config 都在）；② 模块在纯 Node 下可导入且
apply(mockCtx)能跑通并注册技能；③ 宿主里apply()确实启动过（~/.bsk/dsh-starts/...的 journal 文件是证据），但之后全部无效。建议：支持 rc.2；若确实需要更新的 harness，请在文档里写明最低版本并显式报错而不是静默不注册；把技能注册改为非致命（try/catch），避免 SDK 漂移拖垮整个工具集。注：bsk CLI 路线在同机上已端到端验证可用，浏览器侧本身是好的。