DeepSeek Harness 桌面启动器。一个基于 Tauri 的跨平台桌面应用（macOS / Windows），负责在本地拉起 DeepSeek Harness（DSH）服务并打开其 Web 界面，免去手动在终端执行 npx @deepseek-ai/dsh web 的麻烦。
- 一键启动本地服务：应用启动时自动选择一个空闲端口，并通过登录 shell（自动加载 nvm）执行
npx @deepseek-ai/dsh web启动 DSH 服务。 - 启动进度展示：白色系启动界面实时展示服务状态（准备中 → 启动中 → 已就绪 / 出错），错误时给出提示。
- 自动跳转：服务就绪后自动将窗口导航到本地 DSH Web 界面，无需手动打开浏览器。
- 带启动令牌的访问地址：新版 DSH 为每个进程生成一次性启动令牌，只把带令牌的地址打印到 stdout，裸地址（
http://127.0.0.1:<port>/）直接返回 401。启动器读取该行输出并用带令牌的地址打开窗口（服务端随即种下会话 Cookie 并 303 跳回干净地址）；对没有令牌的旧版本自动回退为轮询裸地址。 - 干净退出：关闭应用时自动终止 DSH 服务进程（连同其子进程组），不留后台残留。
- Node.js + npm
- DSH 服务通过
npx @deepseek-ai/dsh web --port <port> --trusted-host 127.0.0.1:<port> --no-open启动，需要网络能访问 npm 仓库以获取包。 - 启动器通过管道读取
dsh web的 stdout，从dsh web: http://127.0.0.1:<port>/?token=…这一行解析出本次进程的访问地址；令牌是进程级随机的、不落盘，所以每次启动都必须重新解析。 - 打开窗口时依次访问
about:blank→ 带令牌地址 → 裸地址。原因：DSH 的会话 Cookie 带SameSite=Strict，而 WebKit 会把“发起这次导航的当前文档”（打包后是tauri://localhost，开发时是http://localhost:1420）当成跨站来源，于是 303 跳转回/时不带 Cookie，窗口会渲染出dsh web authentication required; reopen the URL printed by dsh web.。先清空文档即可去掉该来源；最后再访问一次裸地址（同站请求），既是无害刷新，也是 Cookie 仍被扣留时的兜底恢复。 dsh web默认会把该地址交给系统默认浏览器（DSH 侧openBrowser默认为 true），导致除了应用窗口外再弹出一个浏览器标签页。启动命令已追加--no-open，现在只会在应用窗口内打开。- 服务启动超时时间为 45 秒，超时后界面会显示错误信息。
-
粘贴大段文字后的编辑卡顿：DSH Web 输入框（Lexical 编辑器）把整段文本留在编辑器里，输入一次的开销随草稿长度增长。在 macOS WKWebView（本客户端使用的引擎，可见窗口、含真实排版与绘制）中实测：
草稿长度 每次按键（编辑器内 JS） 每次按键（含绘制） 粘贴 → 绘制完成 5 KB 3–5 ms — — 20 KB / 400 行 3–6 ms — — 97 KB / 2000 行 12–15 ms ≈33 ms ≈100 ms 390 KB / 8000 行 26–32 ms ≈50 ms ≈116 ms 浏览器引擎的排版路径并不是瓶颈所在：同样的内容放进不带任何 DSH 代码的纯
<div contenteditable>时，WebKit 原生输入路径确实很慢（每次按键 ≈115 ms，拆成逐行块级元素后 ≈3 ms），但 DSH 的编辑器由 Lexical 接管输入，不经过该原生路径。把粘贴文本拆成逐行 Lexical 节点（TextNode+LineBreakNode）的方案在真实编辑器里反而严重变差——390 KB 粘贴派发耗时 5.1 s（节点数暴涨使 Lexical 协调开销线性上升），因此本仓库不做该改动；spellcheck、contain、max-height+overflow亦无改善。瓶颈在 DSH 前端（编辑器与草稿状态）内部，启动器无法从外部修复。当前可行的做法：把长文本放进文件，用
@引用或作为附件发送（草稿保持很小），或分多次粘贴；改用系统浏览器打开 DSH Web 界面也能缓解（Chromium 下同等草稿的单次按键 JS 开销约为 WebKit 的 1/3）。