dsh-linux-desktop-entry
在 harness 内安装、修复或移除 DeepSeek Harness Web GUI 的 Linux 桌面入口，并在应用窗口中打开 GUI。
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add github:ShiTan-677/dsh-linux-desktop-entry#1ac378d499f77a8e073943a38bf024936c577330Linux Desktop Entry 以 dsh-linux-desktop-entry 发布，当前版本为 0.1.0。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
点击下方 Badge 复制 Markdown，粘贴到 README 即可。
验证 package.json 声明的 GitHub 仓库，即可管理这个公开页面。认领后，Hub 会优先安排当前版本的安全扫描，并在通过后公开展示结果。
认领这个 Plugin →A DeepSeek Harness plugin that puts the
Linux DSH Web Entry desktop launcher
under the harness's own controls: a page in Settings, an agent tool, and a /desktop-entry
command — all three driving one implementation.
The desktop entry itself — the launcher, the app-menu entry, the trusted desktop icon, and
the optional systemd --user service — comes from the Linux DSH Web Entry project. This
plugin carries a copy of that shell kit and runs it; it never reimplements installing,
removing, or launching.
Settings → Desktop entry agent: desktop_entry composer: /desktop-entry
[Installed] {"action": "status"} /desktop-entry status
Install · Uninstall {"action": "install", /desktop-entry install
Open in app window "systemd": false} /desktop-entry open
Be clear about the boundary, because it is structural rather than a limitation of effort.
| Can | Install, repair, remove and inspect the desktop entry from inside a running harness; open the GUI in a browser app window; opt into a resident service; let the agent do any of it. |
| Cannot | Be the thing that starts DSH when DSH is not running. That is the desktop file's job, and it happens outside this process. |
So the plugin is a second delivery surface for the same desktop entry, not a replacement
for it. If you only want the launcher and never touch plugins, use the shell project
directly — it is a self-contained git clone && ./install.sh.
git clone https://github.com/ShiTan-677/dsh-linux-desktop-entry
Then install the bundle into your profile with the Plugin Manager, pointing at the clone:
plugin_manager install_bundle /absolute/path/to/dsh-linux-desktop-entry
Three prerequisites, each of which produces a specific error when missing:
pnpm on the PATH of the DSH process. install_bundle installs
the package with pnpm add; without it the install fails at that step.install_bundle records a link: dependency, so
the profile points at your checkout. Moving or deleting it breaks the plugin; use the
Plugin Manager to remove the bundle first.Nothing is written to your desktop at install time. The Settings page shows what is on disk and waits for a click.
One page that reports the state and offers the actions: whether each installed file is
present, whether anything is listening on the port, and what the resident unit is really
doing — its path plus is-enabled / is-active, or the reason it is not in use. Buttons:
Install (or Reinstall to repair), Uninstall, Open in app window, Refresh.
desktop_entry agent toolOne tool with an action parameter — status, install, uninstall, open — and an
optional systemd flag. Ask the agent to "install the desktop entry for the harness Web GUI"
and it can inspect first, then act, reporting the installer's own output.
status changes nothing, so it is the safe first call.
/desktop-entry command/desktop-entry # status
/desktop-entry install # desktop entry only
/desktop-entry install --systemd # plus a resident systemd --user service
/desktop-entry uninstall # removes the unit too, when one exists
/desktop-entry open # open the GUI now
Off by default, in every surface. Ticking the box — or passing --systemd — writes and
enables a systemd --user unit so the GUI is served from login onwards.
The cost is honest and stated in the UI: this keeps a node process resident and using resources even while no window is open. The default path starts a server on the first double-click and costs nothing when idle. Pick per machine.
Uninstall stops and removes the unit as well, so removing the plugin's desktop entry never leaves a server running behind you.
If you move the unit, move it for both surfaces: the installer writes it under
DSH_WEB_SYSTEMD_UNIT_DIR, while the launcher only reads DSH_WEB_SYSTEMD_UNIT_FILE. When
the two disagree, the page says so and opening still falls back to a terminal window — a unit
file the launcher never reads is not a resident service.
A unit file is also not enough on its own: the launcher needs a reachable systemd --user
manager, which is why status reports is-enabled / is-active instead of file existence.
vendor/linux-dsh-web-entry/ is a verbatim copy of the
linux-dsh-web-entry runtime payload: the
installer, the launcher, both templates, the icon composer, the payload's own self-test, and
the license. The Host half runs its install.sh and bin/dsh-web-open.sh.
Two repositories were chosen over one so each stands alone: neither breaks when the other is
unpublished, unavailable, or moved. The price of that independence is drift, so it is made
detectable rather than merely documented — tools/selftest-plugin.mjs checks every payload file
against the sibling checkout at ../linux-dsh-web-entry whenever it exists: each must be
present and byte-identical, and nothing outside the list may appear in the copy. A standalone
clone skips that comparison and says so.
PROVENANCE.md records the upstream commit and version, and what re-vendoring means.
node tools/selftest-plugin.mjs # 57 checks: this plugin's surface
vendor/linux-dsh-web-entry/tools/selftest.sh # 36 checks: the vendored shell kit
The plugin self-test drives the Host half's HTTP handlers, the agent tool and the command against a fake Cordis context, so the route contract (trust fence, method, content-type, body ceiling, action validation) and all three callers are checked without a browser or a cookie.
Every installer path — including the systemd --user unit directory — is redirected into a
temporary directory before any handler runs, so the install/uninstall cycle exercises the real
install.sh against a sandbox and touches nothing of yours. For the same reason the test
never asks the installer for --systemd: that path ends in systemctl --user, which resolves
the unit by name through the live user manager.
Visual verification of the Settings page in a browser is not part of the automated test; see Limits.
settings.section), by parse and
syntax checks, and by the route contract its buttons call. It has not been verified by
reading a rendered browser page.locale/en.json and locale/zh.json.systemd install path is exercised only by the vendored shell kit's own self-test, not
through this plugin's route.pnpm reachable from the DSH process.MIT. The vendored shell kit keeps its own copy at
vendor/linux-dsh-web-entry/LICENSE.