DSH Linux Desktop Entry

简体中文

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

What this plugin can and cannot do

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.

Install

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:

• Linux. The plugin reports an unsupported host on other platforms instead of offering actions that cannot work.
• A DSH profile, and pnpm on the PATH of the DSH process. install_bundle installs the package with pnpm add; without it the install fails at that step.
• The clone must stay where you put it. 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.

What you get

Settings → Desktop entry

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 tool

One 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

The resident service is opt-in

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.

The vendored shell kit

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.

Tests

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.

Limits

• The Settings page is verified as a live slot registration (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.
• Visible page text is English only. The harness locale service is not wired up yet; the plugin's own display metadata ships in locale/en.json and locale/zh.json.
• The systemd install path is exercised only by the vendored shell kit's own self-test, not through this plugin's route.

Requirements

• Linux, a desktop entry spec compliant desktop, and a Chromium-family browser for the app window — see the shell project for the details it owns.
• DSH with a profile, and pnpm reachable from the DSH process.

License

MIT. The vendored shell kit keeps its own copy at vendor/linux-dsh-web-entry/LICENSE.