桌面版来了，给 DSH 补了个 Electron 桌面版（file:// + IPC，无需本地服务）

[imlx]

效果图（都是 Electron 原生窗口实拍，下方gif加载较慢，也可看 源视频，建议 ⌘+点击新标签页打开）：

折腾了一个 DSH 的 Electron 桌面版，不用起本地服务那种

一直想要个能直接双击打开的 DSH 窗口，不想每次都 dsh web 起个本地 server 再开浏览器。翻了下源码发现官方其实早就把路铺好了——packages/host/webserver 里写着 "Web shape only — Electron loads dist over file:// and carries fetch over an IPC bridge"，AbstractApiClient.doFetch 也把 IPC bridge 列为预期传输之一。位置都留好了，那我来实现。

代码在 fork 上，欢迎来踩：

分支：https://github.com/imlx/deepseek-harness/tree/feat/electron-transport
设计笔记（中英双语）：.agents/notes/proposed/architecture/2026-08-14-electron-file-ipc-transport.md

大概干了三件事：

• 在 dsh-client-connection 里加了个 ElectronApiClient，unary 走 preload 注入的 window.dshIpc 桥，下行流 override 成走 IPC 推送而不是 WebSocket。apply() 就多了一个分支（?fixture → Electron → 浏览器），重连循环、RPC 校验这些都是复用原来的，没动 core。
• 写了个 apps/electron 主进程壳，进程内拉起一份 profile，用 overlay patch 把所有"起端口/组浏览器图"的行关掉，再把网关桥到 IPC。下行流在主进程里迭代 apiProxy.events 推给渲染进程。
• 没有 webserver 也能组客户端模块图：从各包的 dsh.client 声明重组，bundle 用 file:// 绝对路径，默认 <script src> 加载直接就能跑。

原生能力（比如目录选择）走的是 provider 接缝，没往壳里写死。

踩了两个印象比较深的坑，记一下免得别人再踩：

1. 回环判定。Electron 这条载体得始终算 loopback——它代理的就是进程内的回环 /api 网关，但 file:// 的 hostname 是空的，isLoopbackHostname 会判成非回环。这个一开始没处理，结果所有 settings 作用域全退化成内存态，"插件配置"页整页空白，查了半天才发现是这一行的事。
2. 流开启竞态。主进程一开流就推 baseline 帧的话，渲染进程那边监听还没挂上，头几帧会被 IPC 静默丢掉。现在改成 pump 等渲染进程回个 streamReady 再推。

测试和门禁都过了：connection 包 121 个单测，改动的两个文件保持仓库要求的单文件 100% 覆盖；build/knip/constraints/publint/doc-sync/typecheck/lint 全绿。macOS 上端到端跑过：起窗、过 onboarding、设置页三张卡（Shell / Agent 循环 / 网页搜索）都正常。

主窗口	设置 - 插件列表	会话轨迹

最后补充一下：现在仓库只开了 Discussions，Issues 和 PR 都关着。这套东西基本是照着官方预留的蓝图补全的，规范也都严格按仓库要求走。如果方向 OK，我很乐意整理成正式 PR；要是官方对桌面端另有打算，也麻烦指个方向，我可以配合调整，或者就当个社区维护的可选形态继续养着。

---

跑法：clone fork 切到 feat/electron-transport，cd apps/electron && pnpm start（完成后仅需填入 DEEPSEEK_API_KEY，体验飞速响应）。

[imlx]

补充一下接下来的计划，回应"跑法对普通人太难"这个反馈：

1. 打包成安装包：现在 pnpm start 那套是开发者流程，下一步用 electron-builder 把应用打成 .dmg / .exe，目标就是下载、双击、能用，不需要 node/pnpm/clone。
2. key 在应用里填：实测"设置 → 模型"页填 key 写进凭据存储这条链路在 Electron 里走通，这样大家连 .env 都不用碰，装完打开填一次 key 就完事。

先打个 mac 的 .dmg 试试，做出来会更新到这个帖子里。欢迎有打包经验的朋友提意见。

[imlx]

打包这步打通了 ✅ mac 的 .dmg 已经能打出来、装上也跑得起来（未签名版）。

做法上最折腾的是依赖这块：DSH 主进程是运行时按名字加载一堆插件包的，没法像普通 Electron 应用那样 bundle 成一个 js，得把整棵 pnpm 依赖树"摊平"成真实文件随包分发（pnpm 的符号链接在打包后解析不了，还有循环链接会把拷贝卡死）。写了个收集脚本（collect-runtime.mjs）跟着 Node 的解析把 ~440 个包摊平，native 二进制（sharp/koffi 的 darwin-arm64）走的是 optionalDependencies 也一并带上了。

几个关键点：

• asar 关了——loader 按真实路径解析插件还要建符号链接，asar 的虚拟路径扛不住
• 注入的前端 index 写到用户目录（打包后 dist 在只读的 .app 里），用 <base> 标签把 ./assets/... 指回 dist
• 装好的 .app 实测能起来：完整插件树加载成功，渲染出 onboarding 界面

代码在 feat/electron-packaging 分支：https://github.com/imlx/deepseek-harness/tree/feat/electron-packaging

现在的限制：dmg 没签名，别人装会被 Gatekeeper 拦（右键打开能绕过）。要正经分发得上 Developer ID 签名 + 公证，我正在弄。下一步把"设置→模型里填 key"这条链路在打包版里实测通，这样大家装完打开填一次 key 就能用。

[imlx]

修复了一个启动崩溃 + 顺带瘦了体积。

有同学反馈装的 .app 打不开，报 Cannot find package '@deepseek-ai/dsh-launch-environment'。查了下：主进程顶层的静态 import 走 Node 自己的 ESM 解析（从 lib/ 向上找 app/node_modules），而打包只产出了 runtime/ 那套（给动态 loader 用），漏了 app/node_modules。现在把顶层 import 的几个包镜像进去，就正常了。

体积也从 800M 降到 544M（dmg 152M）——electron-builder 在 pnpm monorepo 里会把整个 workspace 都收进来，得显式排掉。

修复在 feat/electron-packaging 分支，重新打一个 dmg 装上就能用了。

[imlx]

用的时候发现一个事，跟大家同步下，也想听听你们的想法。

插件列表页是只读的，这不是 bug。 我去翻了下官方代码，packages/host/plugin-inventory 只暴露了一个 list 方法——插件列表页就是展示当前 157 个插件的启用/停用状态快照，那个下拉箭头在官方 web 版里也一样不能点。官方的逻辑是：改插件靠命令行和配置文件，不靠 UI：

• 新增插件：dsh plugin add <包名>（本质是往 profile 目录里装包）
• 启停插件：编辑 ~/.dsh/profiles/web/cordis.patch.yml，给对应插件加 disabled: true/false，重启生效

所以"列表里不能调启停、不能直接加插件"这个行为，跟官方 web 版是一致的——它不是把管理功能藏在 UI 里，而是放在 CLI 和配置里。

但 Electron 打包版在这有个真实的坎。 官方 dsh plugin add 是在装好的 dsh 上跑 pnpm 把插件装进 profile 目录；可咱们这个打包好的 .app，插件树是构建时就打平进安装包里的（只读），既没有 dsh 命令行入口，也没法往里装新包。所以**"新增插件"在打包版里目前是真没有**——不只是 UI 没有，是机制上还没有。

想征询下大家的建议：

1. 你更想要在 UI 上点几下就能启停/加插件，还是接受官方这种"改配置文件 + 命令行"的方式？
2. 打包版要不要支持"把外部插件装进 ~/.dsh、启动时从那里加载"这个能力？（这是个需要专门做的特性，工作量中等）

如果你们用桌面版时有别的卡点，也欢迎提。

[LoongSerpent9Realms]

我也做了一个https://github.com/LoongSerpent9Realms/deepseek-harness-installer

[Altairpaca]

我在做一个 DSH-native 的模型策略/profile 分发层 DSHelm，刚整理了一份可复用的桌面宿主验收思路，放在这个 PR 里供参考：Altairpaca/dshelm#5

重点不是再造一个 Electron 壳，而是验证桌面宿主能否像 Web 一样：

1. 从用户可写目录发现 $DSH_HOME/profiles/dshelm
2. 加载外部 @dshelm/dsh bundle，而不是把插件固化在只读 app 包
3. 通过同一个 host projection 渲染 planner / worker / reviewer 的模型选择和 Resolution Trace
4. 更新或卸载 DSHelm 时不影响其他 profile 和产品凭据

PR 里有桌面/窄屏截图、干净 HOME/DSH_HOME 的 profile fixture，以及 source-preview 安装脚本。当前明确是 alpha，npm 还未发布；我没有把源码流程包装成已经可用的一键安装。

如果这个验收方向对官方桌面宿主有帮助，我可以把 fixture 缩成独立的通用插件/profile contract，不绑定 DSHelm。