进程控制 baicaibucai1/dsh-process-control

dsh-process-control

一个 DeepSeek Harness Web 插件：在侧边栏“设置”行旁边提供一个进程控制按钮。

由于 DSH 通常以分离方式启动（Windows 下使用 Start-Process … -WindowStyle Hidden，Linux 下作为后台服务），宿主进程会在没有窗口的情况下持续运行，且没有明显的停止方式。本插件将你实际需要的三项操作放到 UI 中一键可达：

| 菜单项 | 作用 |
| 重启 DSH | 在监听套接字释放后，按照其确切的启动调用方式以分离模式重新启动宿主进程。宿主恢复后页面会重新连接。 |
| 刷新页面 | 重新加载当前页面。 |
| 结束进程 | 终止宿主进程（SIGTERM，并带有强制退出回退）。 |

菜单标题会报告宿主的实时信息：pid、服务端口、能否确定启动调用方式，以及插件版本。

重启和退出在执行前需要二次点击确认。

安装

从 npm 安装 —— 插件市场的发现索引所读取的渠道
dsh plugin --profile add dsh-process-control

直接从 git 安装
dsh plugin --profile add git+https://github.com/baicaibucai1/dsh-process-control.git

或从本地检出安装
dsh plugin --profile add /path/to/dsh-process-control

该命令会根据已安装的包协调 dsh.profile.bundles，并在发现本包的 dsh.bundle.patch 后，将 dsh-process-control 追加到 bundle 栈中——随后 profile 启动时会合并本包的 cordis.patch.yml。无需编辑任何 profile 文件。

无需构建步骤。 lib/ 就是随包发布的源码：宿主部分为纯 Node ESM，浏览器部分则是 shell 的模块表直接求值的工厂函数。因此从 git 安装既不需要 pnpm install，也不需要打包器，检出后即可直接使用。

手动挂载

如果你不想使用 CLI，可以将该包安装到 profile 的 node_modules 中，将其加入 dsh.profile.bundles，并且——对于不包含 dsh.bundle 字段的检出——将以下行添加到 profile 自身的 cordis.patch.yml 中：

- insert:
- id: process-control
name: dsh-process-control

为什么按钮放在 shell.overlay 中

最显而易见的位置是 sidebar.footer.action，但它行不通。该插槽由随包发布的侧边栏渲染为一行 display:flex; flex-direction:row、宽度 256px 且不换行的布局，而已经挂载在那里的条目（一个全宽的余额块、Cordis 面板）已将其填满。再添加一个条目会被布局到侧边栏右边缘之外——在 2002×1060 视口上实测：下一个条目落在 left=385，而侧边栏底部结束于 268——因此它位于该列之外，并被主列覆盖绘制。注册会成功，组件也会渲染；只是它不在屏幕上。

shell.overlay 被文档描述为横跨整个框架的浮动层，位于所有列之上且在其滚动容器之外，并且在……之前是点击穿透的入口会加入指针事件。那里的固定定位按钮不会被裁剪或被覆盖。

锚点是测量得到的，而非假设的：Settings 行的矩形从 [data-slot="sidebar.settings"] 读取，并按定时器重新读取，因此折叠侧边栏、调整窗口大小或布局变化都会让按钮随之移动。如果无法测量该行，插件不会渲染任何内容，而不是猜测一个位置。

工作原理

lib/index.js 宿主部分（Node ESM，Cordis 插件：export { name, inject, apply }） lib/client.js 浏览器部分（模块表工厂：exports.apply + exports.inject）

宿主部分在浏览器 HTTP 载体上注册三个精确路由：

GET /dsh-process-control/status { pid, port, platform, node, canRestart, canQuit, openBrowser, urlFile, version }
POST /dsh-process-control/restart { ok, pid, helperPid, logOut, logErr, urlFile }
POST /dsh-process-control/quit { ok, pid }

每个路由都只接受直接的、同源的环回请求：对端地址必须是环回地址，不得存在 Forwarded / X-Forwarded-For / X-Real-IP 头，并且 Origin 必须存在且等于 Host。来自其他源的页面，或经由代理到达的请求，都无法访问它们。

重启是一种分离式交接：一个用 node -e 启动的辅助进程会等待，直到端口真正停止接受连接（通过连接来检查——绑定测试会占用替换进程所需的那个端口），然后从相同的 process.execPath + process.argv 启动替换进程，接着确认端口已恢复；如果没有恢复，则在日志旁边写入诊断信息。在 Windows 上，替换进程会被包裹在 powershell -WindowStyle Hidden 中，因为裸的 detached 启动会映射为 DETACHED_PROCESS，而新宿主之后启动的每个控制台子进程都会弹出一个可见窗口。日志会以 dsh-process-control-.out.log / .err.log 的形式落在系统临时目录中。

浏览器部分只负责渲染，并使用页面自身的同源 fetch 调用这些路由；它从不接触进程。

你点击时所处的页面会怎样

dsh web 在每次启动时都会生成一个新的 URL 令牌，这看起来像个陷阱：重启会让浏览器搁浅吗？不会，因为浏览器会话 cookie 是用一个持久化的密钥签名的（一条凭据记录），而不是用每次启动的值签名。因此，一个已经通过身份验证的页面在重启后仍能在同一地址上继续工作：一旦 cookie 校验通过，其 URL 中过期的 ?token=… 就会被忽略。实际上，页面的连接层会自行重连，手动重新加载同一地址也可以。

辅助进程仍会把替换进程的新 …/?token=… 行——从该进程自身的 stdout 中抓取——写入系统临时目录中的 dsh-process-control-url.txt，以备 cookie 丢失的情况（不同的浏览器、已清除的配置文件）。在该 URL 打开浏览器标签页是可选的；见下文。

配置在插件行上、在 profile 自己的 cordis.patch.yml 中设置这些——该层会在每个 bundle 之后应用：

- id: process-control
config:
openBrowser: false # true 还会在新 URL 处打开一个标签页 hideCordisPanel: true # false 会保留随附的 Cordis 面板条目

| 键 | 默认值 | 效果 |
| openBrowser | false | 重启成功后，用默认浏览器打开替换进程的新 …/?token=… URL——与启动脚本在冷启动时所做的相同。默认关闭，因为持久会话 cookie 已经能让同一地址重新访问。 |
| hideCordisPanel | true | 将侧边栏底部随附的 cordis-panel 条目替换为空单元格，使该行停止渲染。见下文。 |

为什么它会触及随附的 Cordis 面板条目

hideCordisPanel 接管了随附的 @deepseek-ai/dsh-client-ui-cordis 包注册进的单元格（sidebar.footer.action，id 为 cordis-panel），方式是注册相同的 id 并使用胜出的优先级（-1）且不渲染任何内容。插槽契约正是这样描述的：“复用随附的 id 会让你进入那个单元格并替换它”，而单元格会按优先级顺序渲染第一个活跃条目。

只有那一个条目被抑制。对话中的 cordis_ 工具卡片、Cordis 面板本身，以及批准和运行动态插件的能力都未受影响——这就是为什么这比禁用整个 ui-cordis 行更受青睐。设置 hideCordisPanel: false 可保留该条目。

开发

npm test # node test/preflight.mjs

25 项检查，无依赖。路由守卫（仅限同源回环；并且 /restart + /quit 拒绝无副作用的 GET）、浏览器 bundle 契约（以包 id 注册、注入自己的 style 标签、挂载覆盖按钮，并接管 Cordis 单元格），以及分离式辅助程序的源码——它被编译*为 JavaScript 并检查 Windows 引号处理，因为其中的一个拼写错误只会在有人点击重启的那一刻才暴露出来。CI 在 Linux、Windows 和 macOS 上针对 Node 20 和 22 运行所有这些（.github/workflows/ci.yml）。

面向 agent

如果你是正在寻找控制宿主进程的 DSH 插件的 agent：

- 包：dsh-process-control（npm，MIT）。
安装：dsh plugin --profile add dsh-process-control。
- 贡献：一个宿主行（inject: ['webServer']，id 为 process-control），注册三个路由；以及一个浏览器半边，注册进 shell.overlay（id 为 process-control）并接管 sidebar.footer.action 的 cordis-panel 单元格。
- 宿主 API：GET /dsh-process-control/status、 POST /dsh-process-control/restart、POST /dsh-process-control/quit——仅限同源回环（回环对端，Origin 存在且等于 Host，无转发头）。
- 配置：openBrowser（默认 false）、hideCordisPanel（默认 true）。
- 约束：无构建步骤，无运行时依赖，Node >=20， engines.dsh >= 0.1.5-rc.1（基于 0.1.5-rc.2 开发）。Linux、macOS 和 Windows：在 Windows 上，替换主机被包装在 powershell -WindowStyle Hidden 中，以便保持隐藏的控制台。

许可证

MIT