功能请求：用户级、重启后自动加载的插件目录（含 Client/GUI 插件）

[eeyzs1]

English summary: Feature request for a user-level, restart-persistent plugin directory — including client/GUI plugins — so community plugins can be dropped into a folder and auto-loaded without forking the deployment or rebuilding the web shell.

背景与痛点

我们用动态 Cordis 插件做了两个用户侧插件：

• chime：回合完成 / 等待用户选择时播放提示音（纯 Client）；
• attach-files：输入框「添加文件」按钮 + 文件选择器（Client UI + 少量 Host RPC）。

它们很好用，但有一个共同痛点：DSH 重启后动态插件不自动加载，只能靠 git 仓库收源码 + 重启后人工 cordis_define / cordis_run 恢复。

目前的理解（可能不完整，欢迎指正）

• composition（含用户预设）能引用裸包名 / 相对路径 / 绝对路径三种 specifier，所以纯 Host 插件其实可以打成真实包放用户目录、用绝对路径引用，做到开机自启且升级不丢。
• 但 Client/GUI 插件没有这条路：它必须是一个声明 dsh.client 且导出已构建 ./client bundle 的真实包，由 webServer 以 /plugins/ 服务并注入 window.DSH_BOOT。这需要把包放进 DSH monorepo、跑 web 构建，升级即被覆盖，等于 fork 部署。

请求的功能

希望提供一个用户级、升级安全、重启后自动加载的插件目录（类似 VSCode 的 ~/.vscode/extensions、Obsidian 的插件目录），并且覆盖 Client/GUI 插件。理想形态：

• 往某个用户目录（如 ~/.dsh/plugins//）放一个插件文件夹；
• DSH 启动时自动发现并挂载 Host 插件，同时把 Client 插件纳入 dsh.client 扫描 / 打包（或等效机制）；
• 升级不覆盖用户目录。

安全顾虑（我们理解）

我们理解动态插件「临时 + 需批准」是刻意设计的信任边界（开机自动执行任意代码的风险）。所以不要求「无脑执行任意 JS」，可以是更安全的形态，例如：

• 只加载「声明式 manifest + 受限脚本」；
• 首次安装时显式「信任」该插件；
• 可选签名校验 / 权限声明。

我们只是想表达：社区插件（尤其 GUI 类）目前缺少一个既省心、又升级安全的落地方式，希望团队考虑提供官方入口。

相关

• 插件仓库：https://github.com/eeyzs1/dsh-plugins
• 配套的插件展示见「Show Your Plugins!」分类

谢谢！

[eeyzs1]

补充一个「纯 Host 插件用绝对路径自启」的最小可复现示例。下面基于 loader 源码（agent-presets/src/mount.ts、app-boot/src/index.ts 里 import() 对绝对路径的处理）整理；我们尚未在真实会话里完整跑通 mount 校验，仅供团队参考 / 指正。

1) 一个零依赖的最小纯 Host 包，放在用户自己的目录（如 G:\dsh-plugins\packages\hello-tool\index.mjs）：

export const name = 'hello-tool'

// 零依赖：只使用 loader 注入的 ctx，不 import 任何 @deepseek-ai/* 包，
// 因此放在用户目录（而非 DSH 的 node_modules）里也能被解析。
export function apply(ctx) {
  ctx.on('agent/status', (payload) => {
    if (payload && payload.status === 'idle') {
      console.log('[hello-tool] an agent went idle')
    }
  })
}

导出 name / inject / apply 即满足 loader 的插件契约（真实工具类插件再用 ctx.tools.register(...) 注册工具，inject: ['tools'] 声明硬依赖）。

2) 用户预设 agent.cordis.yml 用绝对路径引用它：

- id: hello-tool
  name: 'G:\dsh-plugins\packages\hello-tool\index.mjs'

loader 的 import() 会把绝对路径转成 file:// URL（Windows 盘符路径正是靠这一步），再走 Node ESM 加载。这样：

• 包在用户自己的 git 仓库里，升级 DSH 不会覆盖；
• 预设只存一行声明，不携带代码。

局限：

• 这只解决「纯 Host / 工具 / 服务类」插件；Client/GUI 插件仍要经过 dsh.client 打包进 web shell，本示例不覆盖——这正是本请求想补上的缺口。
• 包自身的 import 必须能从它所在位置解析（零依赖最省事；带依赖则要处理 node_modules 解析锚点）。

[eeyzs1]

更正：本请求的多数诉求其实已经存在。

我后续通读了 launcher 源码（apps/cli/src/plugin.ts、profile-boot.ts、packages/boot/app-boot/src/profile.ts、packages/client/modules/src/index.ts），发现自己之前判断有误——DSH 已经有一套用户级插件机制：

• dsh plugin --profile web add <包> 用 pnpm 把插件装进 $DSH_HOME/profiles/web（用户目录，升级不覆盖），并在包声明 dsh.bundle 时自动编入组合层；
• 组合层 = 空根 + 各 bundle 的 cordis.patch.yml + profile 自己的 cordis.patch.yml + 全局 $DSH_HOME/cordis.patch.yml，开机自动加载；
• 模块解析锚点是 profile 目录（自带 node_modules），且 $DSH_HOME/profiles/node_modules 有指向安装内包的扁平 fallback；
• GUI 插件走 dsh.client（package.json 里 dsh.client + exports["./client"] 指向构建好的 client bundle），由 clientModules/webServer 以 /plugins/<id> 服务并注入 window.__DSH_BOOT__。

所以「用户级、升级安全、开机自启」的插件目录是存在的，我之前把它当成缺口是错的，抱歉。

仍未确认的点（可能才是真正值得讨论的）：把一个 dsh.client 包放到 DSH monorepo 之外、通过 dsh plugin add 从本地 / git 安装时，其 client bundle 依赖的 @deepseek-ai/dsh-client-* / react / @deepseek-ai/cordis 等注入边能否在浏览器端正确共享解析（Node 端 profile 的扁平 fallback 应该能解析；浏览器端要看 web shell 的模块接线）。我们正尝试用一个最小 client 插件验证这条链，有结论再补充。