dsh-plugin-restart-desktop

DSH 桌面版（DeepSeek Harness Electron 壳）的一键重启插件：保留窗口位置、大小、最大化状态与所在显示器，可选在重启后自动续上被打断的会话（不只是你当前打开的那个）。

只有一个入口：侧栏底部账号行右侧的图标按钮（刷新图标）。单击即重启 —— 没有二次确认，有任务在跑时也不要求再点一次（那一路实况只写进悬停提示）。插件不提供任何设置页配置。

账号行认不出来时（官方改了 DOM）会自动回落到官方给第三方插件的动作座位 sidebar.footer.action（侧栏底部同一行区域的图标按钮），功能不会凭空消失。

另外还注册了斜杠命令 /restart-desktop（一样单击即重启；这条路上的宿主侧警告仍需 /restart-desktop --force 越过）。

为什么需要这个插件

这不是「官方本来就有、只是藏得深」的功能，而是官方没有留任何通道。两条硬事实（都来自解包 app.asar 读主进程源码）：

1. 主进程没有暴露重启。 完整 IPC 只有 shutdown / quit-inspection / update-tasks（主进程 → host）与 ready / fatal / shutdown-complete / platform-session（host → 主进程）；渲染进程侧的 dshDesktop API 只有 browser / deviceInfo / keyboard / shortcuts / updates。内置的「重启应用与 Host」菜单项只在 development 分支里加入菜单，打包版永远看不到；Windows 上托盘菜单只有「打开应用」和「退出」。
2. 窗口几何从不落盘。 createWindow() 硬编码 width: 1280, height: 820，主进程里没有 getBounds 保存、没有 window-state 存储，%APPDATA%\@deepseek-ai\dsh-desktop\ 下也没有任何窗口状态文件。正常退出再开一定回到 1280×820。

还有一条容易踩的坑：窗口的关闭按钮不会退出应用（主进程 preventDefault + hide，只是收进托盘），所以「关掉再打开」这条最直觉的路并不成立。

所以插件只能自己动手：从宿主进程里派一个分离的 helper，由它结束 Electron 主进程、等端口释放、拉起新实例，再逐像素还原窗口。

它是怎么做的

DeepSeek Harness.exe            ← Electron 主进程：窗口、托盘、更新、spawn host
└── DeepSeek Harness.exe      ← host 子进程（ELECTRON_RUN_AS_NODE=1），监听 127.0.0.1:19387
└── 本插件的宿主半
└── （分离）helper：node lib/helper.mjs handoff.json

1. 宿主半校验目标是不是桌面宿主、把「现在停掉会打断什么」讲清楚、写一份交接描述，然后把 helper 拉起来。
2. helper 等 1.5 秒（让 HTTP 响应先送达页面）→ 趁主进程还活着捕获窗口几何 → 结束 Electron 主进程 → 等主进程消失、等端口释放 → 拉起新实例 → 等新窗口出现 → 还原几何。

关键取舍：只杀主进程，不带 /T

主进程一死，host 子进程到它的 IPC 通道断开，host 里的 process.once('disconnect') 会走 application.shutdown.shutdown(0) —— 这和官方正常退出走的是同一个 stop()，会话日志因此正常落盘。带 /T 会把 host 一起强杀，那才是真的可能丢数据。

只有一种情况会碰到 host：端口在主进程消失后仍然不放（说明 host 卡住了）。那一步是最后手段，且会把「它的会话日志可能不完整」如实写进日志。

窗口几何

lib/geometry.ps1 用 GetWindowPlacement 取 rcNormalPosition（用户真正选定的那个矩形 —— 窗口最大化时当前矩形是最大化后的，只有它记录着要还原的尺寸）、showCmd（常规 / 最小化 / 最大化），以及 MonitorFromWindow / GetMonitorInfo（窗口在哪块显示器上，例如 \\.\DISPLAY2），重启后用 SetWindowPos + ShowWindow 放回去，并读回实际值写进日志。

最大化的窗口必须先把位置放回去，再最大化。 Windows 是在「窗口此刻所在的那块屏」上最大化的，而重新拉起的应用总是把窗口创建在主屏（笔记本屏）上 —— 所以对一个最大化的窗口直接 ShowWindow(SW_MAXIMIZE)，等于把住在副屏的窗口拽回笔记本屏。现在的顺序是：退出最大化 → SetWindowPos 到捕获到的正常矩形（它标记着用户当时在用哪块屏）→ 最大化。最小化同理：先放回那块屏再最小化，否则从任务栏还原时会弹到主屏。

还原后还会读回窗口所在的显示器并与捕获值比对，wanted / actual / onTarget 一并写进日志与结果文件。若目标屏仍在、窗口却落在别处（正常矩形跨两块屏时会发生），脚本会把它居中到目标屏再最大化一次，并在结果里标 corrected: true；目标屏已经拔掉时不做任何猜测，只如实报 onTarget: false。

> 这个脚本必须保持 ASCII-only：Windows PowerShell 5.1 对无 BOM 的 -File 脚本按 ANSI 解码，一句中文注释的字节被解码坏之后可能连行尾换行一起吞掉，下一行代码就整行变成注释（实测踩过：还原时静默拿不到目标显示器，wanted 变成 null）。npm test 里有一条断言把这条约束钉住。

调研结论：重启后能不能自动恢复对话

能，但形态不是「续跑那一轮」。结论分三层：

实现走的是官方通道（源码级核对过）：

• ctx.agents.resume({ resumeSessionId, setup }) —— 把持久化会话恢复成活 Agent。setup 会把会话原本的 agent preset 重新挂上，否则恢复出来的 Agent 会丢掉它那一整套工具（bash / read / goal …）；preset 解析不到时降级为「不带 preset 工具恢复」并记日志，而不是整个失败。
• agent.followup(message) —— 往收件箱排一条消息并唤醒驱动。官方 dsh-headless 与 @deepseek-ai/dsh-goal-round-driver 都走这两步。
• 消息的 source.kind 刻意不是 'user'：Chat 把 source.kind === 'user' 的用户消息渲染成用户气泡，其余 kind 渲染成「注入的上下文行」。用自定义 kind，这条自动消息在对话里长得像系统注入 —— 它确实是。
• 消息正文是纯报告（英文），只有两句：The desktop app restarted at … (scheduled by dsh-plugin-restart-desktop). + At that moment this session was running a turn.（或有几条消息在队列 / 几个后台任务在跑；没有明细就写 The state of this session at that moment was not recorded.）。用英文是因为宿主自己注入的元信息本来就是英文（被打断工具调用上的 ToolOutcomeUnknownError），同一层上下文保持同一种语言。不写 "continue" / "do not retry blindly" 这类指令 —— 重试判据宿主已经写在会话记录里，插件再讲一遍既重复，又可能把说错的话永久写进历史，让模型为了「对齐」它去改动本来没坏的东西。旧版标记没有 details 时只陈述「重启过」，不拿名单去推断这个会话当时在干什么。

副作用面被刻意收敛到最小（自动发消息会真的花钱、真的跑模型）：

• 名单由宿主自己在排程那一刻取实况：只接「agent 正在生成 / 跑工具」或「收件箱里有排队消息」的会话 —— 也就是那一轮对话确实被打断了的会话。刻意不是「你当前打开的那个会话」：在一个会话里挂着长任务、切到另一个会话点重启时，被打断的是后台那个；早先的实现把标记落在空闲的当前会话上，于是 not-interrupted，真正被打断的任务一条恢复消息都拿不到（上报现场就是这个形状）；
• 后台任务在跑不算「被打断」，只作为明细记进标记。任务活着不等于对话没结束：实测有一个会话挂着跑了 34 小时的 pnpm dev，而它的最后一轮对话在前一天就正常 turn/end 了；按任务唤醒它只会凭空多跑一轮。应用重启会杀掉后台任务，这件事写在「已知边界」里，不用恢复消息去通知模型；
• 新版标记里的 sessionId 只是状态页展示用的「客户端当前会话」，不参与恢复名单。旧实现把它无条件补进名单，于是用户在哪个会话里点重启、哪个会话就会被续一轮 —— 哪怕它早已结束（真实事故：最后一轮比重启早 3 分钟就完成了）；
• agents / jobs 服务读不到、形状不认识、抛错时名单为空 —— 宁可一条都不恢复，也绝不凭猜测唤醒会话；
• 空闲会话与历史会话永不被唤醒；
• 标记带 5 分钟 TTL：宿主要是在几分钟之后才起来（比如用户手动重开），就不再自动发消息；
• 标记在宿主启动时被取走即删，所以一次重启最多恢复一次，恢复失败也不会在下次启动时重放；
• 一次重启可能接上多个会话，每个各发一条恢复消息；其中一个恢复失败不连累其余，失败原因逐个记进日志。

安装

从 npm 装（推荐）：

plugin_manager(action: "install_bundle", target: "dsh-plugin-restart-desktop")

或者直接写进 profile —— bundles 与 dependencies 两处都要有：

// ~/.dsh/profiles/desktop/package.json
"dsh": { "profile": { "bundles": [ /* … */ "dsh-plugin-restart-desktop" ] } },
"dependencies": { "dsh-plugin-restart-desktop": "^1.0.0" }

开发本仓库时用 link: 指向本地目录，改完代码立即生效：

plugin_manager(action: "install_bundle", target: "link:C:\work\my\dsh\plugins\dsh-plugin-restart-desktop")

安装后 DSH 的 HMR 会当场把两半挂上，不需要重启（实测：安装后宿主路由立即应答，客户端半的图标按钮立即出现在账号行右侧）。如果入口没出现，刷新一次页面即可。

正常情况下 HMR 会当场把两半挂上，不必重启。只有在没开 HMR 的组合里，宿主半才要等 DSH 下次启动；客户端半每次刷新页面重新取。两半版本不一致时，控制台 __DSH_RESTART_DESKTOP__.status().version 是宿主版本、__DSH_RESTART_DESKTOP__.version 是客户端版本。

> 只支持 Windows 桌面版（能力探测不通过会明确拒绝，见「已知边界」）。宿主版本要求见 package.json 的 engines.dsh，作者本机实测于 0.2.1-rc.5。

使用

点侧栏底部账号行右侧的刷新图标：一次点击就排程重启 —— 窗口的位置、大小、最大化状态与所在显示器保留，被打断的会话按宿主实况自动续接；页面随后断开，应用重启并回到原来的样子。

单击即重启意味着不拦你：宿主守卫（有任务在跑 / 插件正在安装）不再要求第二次点击，只在按钮的悬停提示里说明「会打断它们」。斜杠命令那条路仍然保留一次警告（/restart-desktop --force 才是「我看过了」）。

配置

插件没有设置页，界面开关一个都不提供。两个宿主侧行为开关仍有默认值（都是开），需要时改插件 config 或宿主侧设置文件：

// ~/.dsh/profiles/desktop/package.json 里本插件那一行的 config
{ "geometry": true, "resume": true }   // 还原窗口几何 / 自动续接被打断的会话

宿主侧设置文件 ~/.dsh/restart-desktop/settings.json 优先于 config；也可以 POST /dsh-plugin-restart-desktop/api/settings?geometry=0&resume=0 改。

排障

浏览器控制台里有 globalThis.__DSH_RESTART_DESKTOP__：

__DSH_RESTART_DESKTOP__.status()      // 宿主状态快照
__DSH_RESTART_DESKTOP__.button()      // 账号行按钮的注入状态（found / injected / lastReason）
__DSH_RESTART_DESKTOP__.sweep()       // 立刻重扫一次账号行
__DSH_RESTART_DESKTOP__.action()      // 按钮此刻的动作状态

button().lastReason 的取值：injected（这一轮插进去了）、already-present（已经在位）、no-account-row（没找到账号行）、insert-failed、no-document（不是浏览器环境）。

宿主侧的交接记录在 ~/.dsh/restart-desktop/：handoff-*.json、restart-*.log、restart-*.result.json、restart-*.geometry.json（保留最近 20 组）。几何结果文件里除了矩形，还有 wanted / actual / onTarget / corrected（显示器名与矩形），重启后窗口到底落在哪块屏一眼可见。

已知边界（写清楚，免得当成 bug）

• 正在跑的那一轮一定会断，不会自动续跑；自动恢复注入的是一份事实报告，不是「重放那一轮」，也不替模型决定该怎么接着做。
• 正在被工具写入的文件可能停在半路。插件不做回滚。
• 后台任务 / 子 agent / teammate 全部被杀；定时任务在应用关闭期间不会触发。被杀的后台任务不会换来一条恢复消息（对话本身没被打断），需要的话重启后自己再拉起。
• 账号行右侧那个按钮靠观察 DOM。官方没给第三方留「账号行里的按钮」座位（sidebar.settings 是 single 座位，整块由 @deepseek-ai/dsh-client-ui-settings-account 渲染），所以只能等它渲染出来、按官方写死的 data-signed-out + aria-haspopup="menu" 认出那个展开按钮，再顺它往上两层定位到账号行、把按钮插在账号行右边。判据里没有一个哈希类名（官方 CSS 模块类名每个构建都变）。认不出来时不猜：回落到官方 sidebar.footer.action 座位，日志与 button().lastReason 会写明原因。
• 侧栏收起时不显示这个按钮：Windows 上官方本来就把整个底栏（账号行那一片）隐藏了。收起状态下用斜杠命令 /restart-desktop。
• 只支持 Windows 桌面版，而且是能力探测后的拒绝，不是文档约定：
• 非桌面宿主（dsh web / headless）：desktop: false，重启返回 409；
• 非 Windows 的桌面版（macOS / Linux）：desktop: true 但 capabilities.restart: false，重启在写交接描述之前就返回 409，原因写明「当前平台（darwin）还没有实现进程控制驱动」；
• helper 里还有第二道同样的检查：万一交接描述被别的方式塞进来，它会在等待 1.5 秒之前掉头，不会空等 15 秒再空拉三次。
  能力快照由 lib/platform.mjs 统一给出，GET /dsh-plugin-restart-desktop/api/status 的 platform 与 capabilities 字段就是它的原样输出（restart / launchArgs / geometry / alert / reason）。客户端按钮读同一份快照：不支持时直接禁用，悬停提示里就是 reason 那句话。
• 窗口几何依赖 rcNormalPosition 与显示器本身：还原记的是「哪块屏 + 哪个矩形」，比对靠显示器设备名（\\.\DISPLAY2）。重启期间被拔掉或换掉的屏不会凭空回来 —— 此时窗口落在系统给的那块屏上，日志与结果文件里 onTarget: false 会直说（脚本不会往一个不存在的坐标上挪窗口）。各屏 DPI 不同时工作区坐标与屏幕坐标可能不一致，还原结果可能偏移（日志里有 wanted / actual）。

验证情况

已经跑过的（全部通过）：

没有跑过的（诚实说明）：修复后的版本还没有真正重启过一次正在运行的 DSH —— 一跑就会杀掉当前会话。上面的对照实验与多显示器用例用的都是临时编译的靶子程序，生产路径的每一段都被单独验证过，但「在本机完整重启一次 DSH（新版）」以及「真的 resume 一个 Agent 并发出一条恢复消息」这两步，仍然留给你第一次点按钮时完成（~/.dsh/restart-desktop/ 下的 restart-*.log 与 last-resume.json 会把结果如实记下来）。

复现：

cd C:\work\my\dsh\plugins\dsh-plugin-restart-desktop
npm run check        # bundle 一致性 + npm test（本次 85 项）
npm run test:e2e     # 端到端（需要 Windows 桌面会话；多显示器那两条需要在多屏机器上跑，约 20 秒）

发布时的现状：插件仍以 link: 方式常驻作者本机 desktop profile，账号行按钮这条路已经在真实窗口里用过（包括 2026-11-05 15:42 那次由按钮排程的真实重启 —— 会话被打断后按新判据恢复）。

文件结构

index.js                 宿主半：路由、任务守卫、交接、启动后自动续接会话
lib/platform.mjs         平台能力（「本机能不能重启 / 有没有几何驱动」的唯一事实来源）
lib/helper.mjs           分离 helper：重启的实际执行者
lib/geometry.ps1         Win32 窗口几何捕获 / 还原（刻意只用 ASCII）
lib/resume.mjs           重启后自动续上被打断会话（纯逻辑 + 服务缝）
src/client-core.js       客户端纯逻辑：账号行识别判据、重启状态机、提示文案
src/account-button.js    账号行右侧图标按钮的 DOM 注入
src/client-main.js       客户端接线：图标按钮 + 官方座位回落 + 提示浮层
lib/client.js            客户端 bundle（由 build/bundle.mjs 生成，不要手改）
build/bundle.mjs         客户端 bundle 构建（三源文件内联，无外部依赖）
test/fake-dom.mjs        假 DOM（客户端 DOM 注入的离线测试用）
test/                    单元 + 冒烟 + 端到端测试

发布（维护者）

推 v* tag 即触发 .github/workflows/release.yml：校验 tag 与 package.json 版本一致 → npm run check → 发布 → 建 GitHub Release。

认证走 npm 可信发布（Trusted Publishing / OIDC），仓库里不存任何 npm token。 一次性前置（在 npmjs.com 上做）：包的 Settings → Trusted publishing → GitHub Actions，填 railgun20001、dsh-plugin-restart-desktop、工作流文件名 release.yml，允许 npm publish。该配置要求创建后 2 天内完成首次成功发布，所以顺序是「先把包发出来 → 再配可信发布」；npm 要求 CLI ≥ 11.5.1、Node ≥ 22.14。

流程是幂等的：registry 上已存在的版本不会重发，只补一个 GitHub Release —— 所以 v1.0.0 这个 tag 可以照推，首次发布是本地 npm publish 干的，CI 只负责把它挂成 Release。

本地手动发（首次发布只能这么干：可信发布不支持为「还不存在的包」预配置）：

# 本机 npm 默认 registry 是镜像源，登录要显式指官方源；
# package.json 的 publishConfig.registry 已钉住发布目标，publish 不必再带 --registry。
npm login --registry=https://registry.npmjs.org/
npm run check
npm publish

发布内容由 files 白名单决定：index.js + lib/（含构建好的 lib/client.js）+ cordis.patch.yml + README + LICENSE。src/、build/、test/ 不进包 —— 所以发版前必须先 npm run build 并提交，prepublishOnly 里的 --check 会拦住忘提交的情形。

卸载

plugin_manager(action: "remove_bundle", target: "dsh-plugin-restart-desktop")

宿主侧状态在 ~/.dsh/restart-desktop/，可以直接删；浏览器里只剩一个 dsh-plugin-restart-desktop/pending-v1 标记（重启完成后的一次性提示），一样可以直接删。

许可

MIT