[Show & Tell] 关掉终端 dsh 就没了？我做了一个 macOS 常驻服务管理器

[TristanXS]

这两天折腾 dsh 挺开心的。Everything is a plugin 这个理念在 agent harness 上落地得比我预期的要干净，Cordis 那套组合方式也值得慢慢来看，感谢官方把它开源出来。

我这两天试 DSH 时碰到一个很实际的问题：npx @deepseek-ai/dsh web 会一直占着终端，关掉终端或者重启电脑之后都得手动再跑一次。于是花一天写了个小东西——DSH Service。

它不是桌面套壳，也没有改官方的 Web UI，只是单纯把 DSH 安装成一个 macOS 用户服务：登录自启、异常退出自动拉起。顺带因为它接管了安装这一步，版本也就固定下来了，更新失败会自动回滚到上一个健康版本。

目前只有 macOS 版。Linux 版正在做；Windows 我手头没有设备，实在没法测，如果有用 Windows 的朋友愿意一起来搞就太好了。

也先讲清楚定位：这是个临时方案，不是要跟官方抢什么。哪天官方出了自己的服务化方案或者桌面端，这个项目就该退场，我会很高兴地在 README 上写 deprecated。在那之前，如果它能帮到同样被绊住的人，那就够了。

仓库：https://github.com/TristanXS/dsh-service （MIT，中英双语 README）

git clone https://github.com/TristanXS/dsh-service.git
cd dsh-service && ./install.sh
dsh-service status
dsh-service open

它和 npx @deepseek-ai/dsh web 有什么不同

前台 npx	dsh-service
跑在当前终端里，关了就没	一个 per-user LaunchAgent，登录即起
进程退出就停	异常退出后自动重启
没有状态可查，也没有恢复机制	生命周期命令和更新都走健康检查
每次都要手动敲命令启动	安装版本化 release，激活失败自动回滚

几个我觉得值得说的设计

• 不跑 npx。 安装和更新会把 @deepseek-ai/dsh 解析到一棵私有的、版本化的 release 目录树里，并记录 Node 可执行文件的绝对路径，由 launchd 直接调用入口。好处是"当前跑的是哪一版"一直是明确可查的，换版本只发生在你显式执行 update 的时候。

• 更新是事务式的，中断也能恢复。 先 stage 并校验候选版本，写一份 activation journal，切换 current / previous 链接，再启动服务并验证端口归属和 Web 健康——全部通过才清 journal、剪枝旧版本；候选不健康就恢复并验证上一个版本。就算回滚本身被打断，manager 也不会删掉未验证的 release，status 会报 interrupted，跑一次 restart 把记录的激活过程走完。

• 卸载不动你的数据。 ~/.dsh 是 DSH 自己的用户状态，manager 不碰它；uninstall 清掉所有 manager 拥有的路径，但完整保留 ~/.dsh——这条在 smoke test 里是显式验证的。

installer 自身的事务性、完整路径清单和各状态的恢复语义都写在 README 里了。

关于安全，有件事得说在前面

这不是我的发现，也不是 DSH Service 引入的问题：@mxym 在 #250 里指出，DSH 的 Web 控制面目前只靠 loopback 可达性判断调用者身份，并不区分"用户的浏览器"和"本机其他进程"——sandbox 内的模型进程可以连上同一个控制面替用户回答 approval，他也给出了实机复现。建议直接读原帖，比我转述准确。

常驻会放大这个问题的暴露时间：以前只有我开着终端时它才在，现在是我一登录它就在，崩了还自动拉起。所以：

服务只绑 127.0.0.1，本版本没有端口设置，也不会提供 --host 0.0.0.0 这样的开关
在上游修复之前，不建议把它跑在存有敏感凭据的机器上
只绑 loopback 只是减少了网络层面的暴露，它不会把 DSH 关进沙箱，也不会验证本机调用者的身份

常驻确实方便，但这份方便是有代价的，我觉得应该先讲清楚。

现状

Public alpha。验证环境 macOS 26.5.2 / arm64 / DSH 0.1.0-rc.6，live smoke 覆盖 install、status、restart、同版本 update、stop、start、uninstall。跨版本激活目前只有隔离测试覆盖——公开发布至今只有一个版本，还没出现过真实的版本跳变，下一版发布时我会把实测补上。换个环境不一定能跑，v1.0 之前命令和路径也可能还会变。

DSH Service 的 bug 请提到它自己的仓库（https://github.com/TristanXS/dsh-service/issues ），别开到官方这边来。附上 macOS 版本、架构、Node 版本和 dsh-service status 输出（不要贴 API key 或 ~/.dsh/.credentials.yaml 的内容）。平台需求去 https://github.com/TristanXS/dsh-service/discussions 说一声，我按呼声排优先级。

[Electricitysheep]

关终端 dsh 就没了——常驻服务管理器正是桌面端体验的关键补位（和 DeepSeek Desktop 桌面封装是同一需求的不同层）。

已收录进手册生态章节（桌面/常驻家族）：https://github.com/Electricitysheep/dsh-handbook/blob/main/docs/07-ecosystem.md

[TristanXS]

谢谢收录，也谢谢你写这本手册——官方文档偏架构，从零上手那条路径确实是不可或缺的，毕竟并非所有人都是技术人员，还是希望有更多的朋友来一起体验，降低上手门槛。

"不同层"我很认同：桌面封装解决的是有没有独立入口，服务管理器解决的是进程要不要一直活着、版本怎么管。其实可以叠加——桌面壳完全可以指向一个已经在后台跑的常驻服务。

btw，麻烦帮忙在条目里标一下：目前只有 macOS 版（Linux 还在做ing，有 Windows 的大佬愿意帮帮忙处理一下 Windows 版本就更好了 hhh），还是 public alpha～

[TristanXS]

DSH Service — run DeepSeek Harness as a macOS user service (login startup, health checks, automatic rollback)

I've enjoyed poking around DSH these past couple of days. "Everything is a plugin" lands more cleanly in an agent harness than I expected, and the way Cordis handles composition is worth a slow read. Thanks to the team for open-sourcing it.

One practical thing kept getting in my way: npx @deepseek-ai/dsh web holds onto your terminal, and once you close it — or reboot — you have to start it by hand again. So I spent a day building a small thing: DSH Service.

It isn't a desktop wrapper, and it doesn't touch the official Web UI. All it does is install DSH as a per-user macOS service: starts at login, comes back after an unexpected exit. And since it takes over the install step, the version stops being a moving target — a failed update rolls back to the last healthy release.

macOS only for now. A Linux version is in progress. I don't own a Windows machine and can't test one, so if any Windows users feel like pitching in, that would be great.

Let me be clear about what this is: a stopgap, not a competitor. The day the team ships its own service mode or a desktop app, this project should step aside, and I'll happily mark it deprecated. Until then, if it saves someone else the same hassle, that's enough.

Repo: https://github.com/TristanXS/dsh-service (MIT, README in English and Chinese)

bash

git clone https://github.com/TristanXS/dsh-service.git
cd dsh-service && ./install.sh
dsh-service status
dsh-service open

How it differs from npx @deepseek-ai/dsh web

Foreground npx | DSH Service -- | -- Runs in your terminal; close it and it's gone | One per-user LaunchAgent, up at login Stops when the process exits | Restarts after an unexpected exit No status to check, no recovery | Start, stop, and update all confirm health first You type the command every time | Installs versioned releases; failed activation rolls back

A few design decisions worth mentioning

No npx. Install and update resolve @deepseek-ai/dsh into a private, versioned release tree and record the absolute path to the Node executable, which launchd invokes directly. You can always tell which build is running, and the version only changes when you run update yourself.

Updates are transactional, and interruptions recover. The manager stages and validates the candidate, writes an activation journal, switches the current and previous links, then starts the service and verifies both listener ownership and web health — only then does it clear the journal and prune old releases. If the candidate isn't healthy, it restores and re-verifies the previous release. Even if the rollback itself gets interrupted, the manager keeps the unverified release rather than deleting it; status reports interrupted, and a single restart finishes the recorded activation.

Uninstall leaves your data alone. ~/.dsh is DSH's own user state, and the manager never touches it. uninstall removes every path the manager owns and keeps ~/.dsh intact — the smoke test checks this explicitly.

The installer's own transactional behavior, the full list of installed paths, and the recovery semantics for each state are all in the README.

One thing about security, up front

This isn't my finding, and it isn't something DSH Service introduces: in #250, @mxym points out that DSH's web control plane currently decides who a caller is based on loopback reachability alone, without distinguishing your browser from any other local process — a model process inside the sandbox can reach that same control plane and answer approval prompts on your behalf. He includes a working reproduction. Read the original; it's more precise than my summary.

Running as a service widens the window. Before, it was only there while I had a terminal open; now it's there from the moment I log in, and it comes back on its own if it dies. So:

• The service binds to 127.0.0.1 only, this release has no port setting, and it will not ship a --host 0.0.0.0 switch
• Until this is fixed upstream, I wouldn't run it on a machine holding credentials you care about
• Binding to loopback narrows network exposure; it doesn't put DSH in a sandbox, and it doesn't verify who the local caller is

Running it as a service is convenient, but that convenience has a cost, and I'd rather say so up front.

Where things stand

Public alpha. Verified on macOS 26.5.2 / arm64 with DSH 0.1.0-rc.6; the live smoke covers install, status, restart, same-version update, stop, start, and uninstall. The cross-version activation path is currently covered by isolated tests only — there's been just one public release so far, so no real version bump has happened yet. I'll add live results when the next one lands. Other setups may behave differently, and commands and paths may still change before v1.0.

Bugs in DSH Service belong on its own tracker — https://github.com/TristanXS/dsh-service/issues — please don't open them here. Include your macOS version, architecture, Node version, and dsh-service status output (don't paste API keys or the contents of ~/.dsh/.credentials.yaml). Platform requests go to https://github.com/TristanXS/dsh-service/discussions; I'll prioritize by demand.

[Electricitysheep]

感谢分享——"桌面壳指向常驻服务"这个叠加思路很对，两条路线其实互补。

条目已标注：目前仅 macOS（Linux 开发中，Windows 欢迎贡献），public alpha 状态。https://github.com/Electricitysheep/dsh-handbook/blob/main/docs/07-ecosystem.md