wbb316/dsh-profile-sync
profile 间插件迁移:把网页版(web)的插件集安全牵引到桌面端(desktop)—— 算差异、预检、生成退出后执行的脚本、重启后核对
Project Overview项目介绍
dsh-profile-sync is a plugin-migration utility built specifically for the DeepSeek Harness ecosystem, designed to move plugin sets between profiles using the default direction of web → desktop. The tool deliberately performs no installation itself: it only computes a diff between two profiles, runs preflight checks, writes an "after-quit" execution script, and reconciles whether the migration actually landed the next time the host starts; real installation is delegated to the official channel, which is the in-app plugin manager for the desktop profile and dsh plugin CLI for web or headless profiles. Integration happens by double-clicking install.cmd while DeepSeek Harness is running, which calls the in-app manager's /api/plugin-manager endpoint and waits until the host half becomes visible in the installed-packages list.
A typical workflow begins in the new left-rail "插件迁移" panel where the user picks a source and target profile, sees a categorized diff (added, changed, version-only, new bundle, new allowBuilds, blockers, advisories), and triggers generation of an apply.cmd for offline use. Command-line users can run node bin/plan-cli.mjs plan --source web --target desktop --write to materialize plans/<timestamp>/plan.json plus plan.txt and apply.cmd, then verify with node bin/apply.mjs --status after restart, while --dry-run, --rollback, and --prune give dry visibility, snapshot rewind, and explicit target pruning respectively. The tool also exposes the profile_sync agent tool with actions plan, write, status, and profiles, and ships six test files totaling 79 cases that run without booting DSH, opening ports, or invoking pnpm.
Hard dependencies include Node.js 20+ resolvable on PATH, a manifest with matching name, cordis.patch.yml mount name, and client id, plus a dsh.bundle.patch declaration to avoid the silent "packaged but never loaded" failure. Limits are explicit: cordis.patch.yml instance-level config (ports, pet coordinates, Tailscale addresses) is intentionally reported only, never copied; explicit-directory profiles are rejected; the CLI cannot touch the desktop profile because @deepseek-ai/dsh/lib/bin.js hard-blocks it; and offline apply.cmd must be executed after the target profile quits. License is MIT, and first-run caveats include running the preflight node bin/check.mjs before installing and verifying the client audit with node bin/verify-client.mjs plus a positive control.
dsh-profile-sync 是一个面向 DeepSeek Harness 的插件同步工具,专门在不同 profile(默认 web → desktop)之间迁移插件配置。它本身不直接安装任何东西,只负责计算差异、执行预检、生成退出后运行的脚本,并在下次启动时核对迁移结果;真正的安装动作交给桌面端应用内管理器或 dsh plugin CLI。安装时需运行 install.cmd,桌面端必须在运行状态以接入 /api/plugin-manager 端点,宿主半通过 HMR 即时生效。
典型使用流程:用户在左侧栏「插件迁移」面板选择源与目标 profile、查看差异报告、生成 apply.cmd 并核对上次迁移状态;命令行用户也可直接调用 node bin/plan-cli.mjs plan|status 与 node bin/apply.mjs --dry-run|--rollback。它适合需要在多台机器或多 profile 间保持插件一致性的 DSH 重度用户,以及负责维护多份环境配置的开发者和测试人员。
依赖方面需要 Node.js 20+ 在 PATH 上;插件以 link: 方式注入,宿主 manifest 必须包含 dsh.profile.bundles。已知限制包括不自动同步 cordis.patch.yml 实例配置、不支持显式目录形式的 profile,且目标端必须为 profiles/<名字> 标准结构。许可证为 MIT,运行时不消耗端口或执行 pnpm,但生成的离线 apply.cmd 需要目标 profile 退出后执行。
请帮我安装这个 DSH 插件。安装前先完成【兼容性检查 + 安全性检查】,检查通过再动手。
插件:dsh-profile-sync(wbb316/dsh-profile-sync)
仓库:https://github.com/wbb316/dsh-profile-sync
本站详情页:https://www.yhbd.top/plugins/wbb316-dsh-profile-sync/
本站登记:类型 client · 归类 原生 DSH 插件 · 许可证 MIT · ⭐ 3 · 最近提交 2026-10-01 · 主语言 JavaScript
按下面顺序执行,每步先把结论告诉我,再进入下一步:
【1 兼容性检查】
① 我这边:DSH 版本、Node 版本、操作系统、当前 profile(web / desktop)。
② 读它的 README、package.json、插件 manifest,列出它要求的 DSH 版本 / Node 版本 / 操作系统 / 外部依赖 / 需要另外先装的运行时。
③ 逐条比对,结论只写「满足 / 不满足 / 未知」三种;不满足的给出可行替代方案。
④ 检查是否和我已装的插件冲突:命令名重复、skill / tool 重名、端口占用、重复注册的 MCP server。
【2 安全性检查】
① 仓库可信度:和上面「本站登记」是否一致;star / fork 数、创建时间、最近提交,是否归档或长期停更。
② 安装脚本:逐行看 package.json 的 preinstall / install / postinstall,以及 install.sh、setup.ps1 之类脚本。出现 curl|bash、下载后直接执行、混淆代码、访问与插件功能无关的域名,立刻停下来告诉我,不要继续装。
③ 依赖:列出新增依赖,标出无人维护、或与知名包拼写近似的可疑包(typosquatting)。
④ 权限与副作用:它会读写哪些目录、访问哪些域名、需要哪些 DSH 权限(filesystem / network / shell / clipboard 等),以及怎么卸载和回滚。
⑤ 如果它要求 sudo / 管理员权限,或权限明显超出功能所需,先停下来问我。
【3 安装】
上面两步没有「不满足」和「高危项」时才执行;用官方推荐方式安装,不要自行提权。
【4 汇报】
用表格输出:检查项 / 结论 / 依据 / 是否需要我决策。拿不准的一律写「未知」并说明要我怎么确认——不要猜,也不要替我决定。
Send this message to DSH in your current session: it verifies compatibility and security first (answering met / not met / unknown item by item) and only installs once everything checks out — it will stop and ask you if it finds a high-risk item. The box scrolls; the copy is the full prompt. CLI install commands may not be accurate across systems, so DSH is the safer route.把上面这条消息直接发给当前会话里的 DSH:它会先核对兼容性与安全性(逐条给「满足 / 不满足 / 未知」),确认没问题再安装,有高危项会停下来问你。框内可滚动,复制到的是完整提示词;安装命令不一定准确,发给 DSH 更稳。
- Only 3 stars - very few users, little community feedback星标只有 3,几乎没人在用,遇到问题缺少社区反馈
- Desktop client: installation downloads an executable - verify the publisher and checksums桌面客户端:安装会下载可执行文件,请核对发布者与校验和
DSH walks through these 9 checksDSH 会逐条核对这 9 项
Compatibility兼容性
- DSH, Node, OS and profile requirementsDSH 版本 / Node 版本 / 操作系统 / profile 是否满足要求
- External dependencies and runtimes (Electron / Python / Docker, ...)外部依赖与运行时(Electron / Python / Docker 等)是否齐备
- Conflicts with installed plugins: command names, skill / tool names, ports, duplicate MCP registration与已装插件是否冲突:命令名、skill / tool 重名、端口占用、重复 MCP 注册
Security安全性
- Repo matches the facts registered here; archived or abandoned?仓库是否与页面登记一致,是否归档或长期停更
- Safety of preinstall / install / postinstall and install.sh / setup.ps1preinstall / install / postinstall 与 install.sh、setup.ps1 是否安全
- curl|bash, download-then-execute, obfuscation, unrelated domains → stop immediatelycurl|bash、下载即执行、混淆代码、无关域名 → 立刻停止
- Typosquatting or unmaintained packages among the new dependencies新增依赖里有没有 typosquatting 或无人维护的包
- Requested permissions vs. what the feature actually needs申请了哪些权限、是否超出功能所需(filesystem / network / shell / clipboard)
- Any sudo / admin requirement, plus uninstall and rollback是否要求 sudo / 管理员权限,以及卸载与回滚方式
Anything uncertain must be marked unknown with a note on how to confirm it. This site's signal screen is a static snapshot, not a security audit.拿不准的必须标「未知」并说明要我怎么确认。本站的信号筛查是静态快照,不能替代安全审计。
Or use CLI install (for developers)或使用命令行安装(适合开发者)
CLI Install命令行安装
dsh plugin --profile web add github:wbb316/dsh-profile-sync
把 wbb316/dsh-profile-sync 加入你的 DSH 配置(web profile)即可启用。
READMEREADME
dsh-profile-sync
在 dsh 的各个 profile 之间迁移插件。默认方向是 网页版 web → 桌面版 desktop。
它的定位很窄:自己不装任何东西。它只做四件事 —— 算差异、预检、写一个「退出后执行的脚本」、
下次启动后核对是否真的落地;真正的安装交给官方通道(桌面端走应用内管理器,其它 profile 走 dsh plugin)。
装完的效果:左侧栏多一个「插件迁移」面板 —— 选源/目标 → 算差异 → 勾选这次要迁哪几个插件 → 生成执行脚本 / 当场应用 → 核对上次迁移。
两条写入路径(以及为什么不是"一键")
dsh 里改一个 profile 有两条合法路径,取决于那个 profile 归谁管:
| 目标 profile | 谁有权写 | 走哪条 | 应用时机 |
|---|---|---|---|
desktop(归桌面应用管) |
应用内的官方插件管理器 | installBundle(cordis 服务 pluginManager,就是「设置 → 插件」用的那个) |
当场生效,不用退出 |
web / headless(归 CLI 管) |
dsh CLI |
dsh plugin --profile <p> install,或用本插件生成的离线脚本 |
目标端退出后 |
桌面端 profile 禁止用 CLI 改 —— 这是硬拦,不是"要先退出"。
@deepseek-ai/dsh/lib/bin.js 里有一条按名字拦住一切 CLI 调用的守卫:
function rejectElectronProfile(program, profile) {
if (profile.toLowerCase() === 'desktop')
program.error('error: profile "desktop" is managed exclusively by the Electron application')
}
它对所有 CLI 调用生效,连 dsh --profile desktop --dump-config 都会被拒
(dshmarket 源码里也留着同一句注释:Never fall back to dsh plugin --profile desktop: that CLI is forbidden.)。
所以桌面端这一侧,本插件只调用官方管理器:改 dependencies、注册 dsh.profile.bundles、
跑兼容性校验、失败回滚都由它负责 —— 本插件不自己写 manifest。命令行的 plan / apply
是给 web / headless 这类由 CLI 拥有的 profile 用的。
要搬的不是 node_modules,是五样东西
少一样就会静默失效:
| 要搬的 | 漏掉 / 搬错的后果 |
|---|---|
package.json 的 dependencies |
包装不上,加载失败 |
package.json 的 dsh.profile.bundles |
包装了但永远不会加载,而且不报错 —— 最阴的一种失败 |
pnpm-workspace.yaml 的 allowBuilds |
pnpm 静默跳过原生构建(比如 node-pty 的 conpty.dll 铺不出来) |
compatibility.json 里的精确版本豁免 |
目标核心不认识该插件时,只给你一句看不懂的拒绝 |
cordis.patch.yml |
故意不同步,见下 |
故意不同步的那一份:cordis.patch.yml
里面装的是实例配置,不是插件配置:端口(web 绑 3080、桌面端绑 19387)、宠物坐标、
remote-web-ui 的 Tailscale 地址。整份抄过去会直接端口冲突。
所以本插件只把差异列出来给你看,一个字节都不写 —— 这是设计,不是没做完。
安装
桌面端不用退出 —— 恰恰相反,它必须在运行(要调用的那个官方管理器就在应用里面):
1. 打开 DeepSeek Harness(正在运行就对了)
2. 双击 install.cmd
3. 刷新页面 —— 左侧栏出现「插件迁移」
install.cmd 做的事:装前自检 → 确认官方的 /api/plugin-manager 端点在跑 →
把 link:<本目录> 提交给应用内的官方管理器 → 轮询到包真的出现在已装列表里才算成功。
两个路由族别搞混。 本插件走的是
/api/plugin-manager/*(REST,回环直连、 不需要 cookie);0.2 里另有一族/api/pluginManager/<method>(Typert Remote), 那族要浏览器会话 cookie,脚本直接 POST 会拿到401 unauthorized。 它不是本插件要走的通道。实测(DSH 0.2.0-rc.2):GET /api/plugin-manager/list→200带真实插件列表;POST /api/plugin-manager/install给个空 body →400 install needs a spec—— 路由活着、body 被解析、身份根本没被校验。
Showing the opening section of the README — the full document lives in the repository以上为 README 开头摘要,完整文档在仓库内 · View the full README on GitHub →在 GitHub 查看完整 README →
honghuachen/deepseekharness-desktop
flizzywine/dsh-tavern
baihejiangnan/deepseek-harness-desktop
HakureiMonika/dsh-sandbox-escalation-fix
PerryLink/dsh-claude-move
MutaLucem/dsh-plugin-integration