dsh-update-status

DSH Update Status

Features · Install · Usage · Update check · Supervised restart · LAN pages · Compatibility · Configuration · Troubleshooting · Security · Uninstall · Release guide

DSH Update Status is a community plugin for DeepSeek Harness. It does not modify DSH core, install or upgrade DSH, roll back DSH packages, download releases, or replace DSH files. It can request a safe restart only after you explicitly install a verified user-level service to supervise the current DSH Web process.

It shadows only the expanded sidebar brand name with DeepSeek plus a compact version chip that fits the 24px brand row, leaving the official fish mark untouched. A green dot next to the version means the running release is the newest one npm publishes; a breathing amber dot means a newer release exists — stable, release candidate or alpha. Tap the chip for the running version, the newer release, whether this plugin was verified against it, a copy-only upgrade command pinned to that exact version, and the guarded Restart control that appears once you have installed user-level supervision.

Features

• Visible version status — shows the running DSH version in the expanded sidebar. Nothing is rendered while the sidebar is collapsed: DSH's sidebar.footer.action row is a single 36px cell above Settings, and a second registrant overflows it (it pushed a neighbouring plugin's entry off the screen edge), so the brand-row chip is the only entry.
• Quiet update signal — a pending update never repaints the version chip. Only an amber dot with a soft halo next to the version breathes (scale + glow; the animation is disabled under prefers-reduced-motion), so a new release reads as one small light instead of a recoloured brand row.
• Three dot states, one glance — with nothing to do the dot beside the version is a plain green circle (the theme's success colour, not the text colour, so a dark shell no longer paints a dot that reads as "off"). While a check is running it is the neutral grey pulse; a pending update is the amber halo. Only the update state animates or glows, and only a failed status read repaints the chip, in red.
• Neutral chip surface — the chip is a grey second-level surface in both themes (#f1f3f5 light / #353638 dark) with the theme's normal label colour, so the dark shell gets a dark grey chip with white text rather than a white pill that hides the amber halo.
• Light, dark, or system — followed automatically — every colour the plugin renders is a DSH semantic token, so the chip, the dot, its halo and the panel all resolve through whatever appearance DSH is using. Set DSH to light, to dark, or to system and the plugin switches with the shell: no plugin-side theme setting, no media query to keep in sync. Hover lifts the chip in both directions (darkened in light mode, lightened in dark mode) by mixing the theme's label colour into the surface.
• One release line, zero configuration — reads npm's dist-tags in one registry request and keeps only the newest published version, stable, release candidate or alpha alike. There is no channel to follow and no choice to make.
• An honest prerelease comparison — the running version and that newest version are ordered with SemVer, so 0.2.1-rc.3 outranks 0.2.0-rc.2 and a release candidate still sorts below its own stable release.
• Compatibility labels — a release this plugin was verified against is marked verified; an untested newer one is marked unverified rather than claimed safe, and that advisory never repaints the chip.
• Copy-only guidance — generates an installation-kind-aware command for the exact newer version it found, never a dist-tag that can move, and never executes it.
• Cache without polling — one Host check on mount, a configurable 30–1,440 minute cache, single-flight registry access, and no frontend polling. Only the Check for updates button bypasses the cache.
• Mobile-safe panel — uses a modal browser top layer so the scrollable, safe-area-aware bottom sheet stays above the DSH drawer.
• Supervised safe restart — after a one-time service setup, the panel can restart DSH for you: it warns about the work it would interrupt, and refuses outright when DSH was started by hand or by the desktop app.

Install

Requirements:

• DeepSeek Harness with the Web profile
• Node.js 20 or newer
• Verified DSH releases: 0.2.1-rc.3 (current), 0.2.1-rc.2, 0.2.1-alpha.5, 0.2.1-alpha.4, 0.2.1-alpha.3, 0.2.1-alpha.1, 0.2.0-rc.2, 0.2.0-rc.1, 0.1.7-rc.2, 0.1.7-rc.1 and 0.1.7-alpha.2

With an installed dsh command:

dsh plugin --profile web add dsh-update-status@latest

From a DeepSeek Harness source checkout:

corepack enable
pnpm install
pnpm dsh plugin --profile web add dsh-update-status@latest

Restart the existing DSH process after installation, then refresh its Web GUI. Do not start a second Web server for this plugin.

Local development link:

pnpm install --frozen-lockfile
pnpm run build
dsh plugin --profile web add "link:$(pwd)"

Usage

1. Open the DSH sidebar drawer. The official fish remains in place; the name row shows DeepSeek plus the current version badge.
2. Tap the badge. The update panel opens without triggering the parent New Session action.
3. Read the running version. When it is the newest release npm publishes, the panel says so and offers nothing to run.
4. When a newer release exists — stable, release candidate or alpha — the panel names it, its publish date, and whether this plugin was verified against it.
5. Copy the generated command, which is pinned to that exact version, and run it yourself in a terminal on the computer hosting DSH.
6. After the package-manager command completes, use the panel's Restart control only if you have completed supervised restart; otherwise restart DSH yourself.

Example commands generated for a global install:

npm install -g @deepseek-ai/dsh@0.2.1-rc.3

The plugin displays one command that matches the detected installation kind and names the exact release it found. It does not run it.

What the dot means

The dot beside the version carries the whole status, and only the update state animates:

Dot · State · Meaning green circle · up to date · The running release is the newest one npm publishes. The chip keeps its normal fill. grey pulse · checking · A status read is in flight (first mount or Check for updates). amber dot with a halo · update · A newer release exists. Copy the command, run it yourself, restart DSH. chip turns red · failed read · The plugin could not determine the state: the registry read failed or the two versions are not SemVer-comparable. An *unverified* newer release is not this case — it is an advisory shown only in the panel.

The chip itself is a neutral second-level surface — grey in both themes, with the theme's own label colour — so the amber halo always reads against it, and it never changes colour to announce an update.

Update check

The plugin asks the npm registry for @deepseek-ai/dsh once per cache window, keeps the newest version any dist-tag points at, and compares it with the running release. latest, next and alpha are npm bookkeeping, not a user choice: a newer release is reported whichever tag carries it.

• The highest SemVer wins, prereleases included, so an alpha ahead of the stable line is offered rather than hidden.
• The comparison is exact: 0.2.1-rc.3 is newer than 0.2.0-rc.2, and both sort below 0.2.1.
• A dist-tag the plugin has never heard of still counts — the read takes every tag npm returns, not a fixed triple.
• Only a version this plugin was verified against is labelled verified. An untested newer release is offered with an *unverified* advisory (notice, which never repaints the chip).
• The detail panel renders one answer; the upgrade command names the exact version found.

Nothing here installs anything. Choosing to follow a channel — and the channel preference that stored it — was removed in 0.2.0.

Supervised restart

A plugin cannot restart DSH on its own: it lives inside the very process it would have to replace. So the button only works once your operating system owns that process — and every OS already ships a way to do that.

The shortest safe setup is explicit and terminal-driven:

# 1. Inspect the complete native-service plan. This writes and starts nothing.
dsh plugin --profile web exec dsh-update-status-service plan \
  --workspace "$PWD" --dry-run

# 2. Stage the user-service definition. This still does not start it.
dsh plugin --profile web exec dsh-update-status-service install \
  --workspace "$PWD"

# 3. Stop the terminal-started dsh web yourself, then activate the service.
dsh plugin --profile web exec dsh-update-status-service activate

activate stops if the port is still busy instead of killing anything, so the DSH you are already using is never taken down by surprise. It also checks afterwards that the service it just started really took over; a service that begins failing immediately is reported as a failure, not as a success. From then on, Restart lists what is running, asks for a second confirmation when something is, and lets DSH exit; the service starts it again and the page comes back on its own.

Only one thing may start DSH Web on that port. If another tool starts its own dsh web — a second plugin's restart helper, a nohup script — that process holds the port while your service keeps failing to start. The plugin asks your operating system which process the service really owns, so Restart stays disabled in that state instead of promising a recovery that cannot happen, and it shows the two copy-only commands that fix it: one to find whoever holds the port, one to give the service back. The generated service also stops after a few failed starts in a row rather than respawning forever, and writes the reason to its log. More detail: user-service supervision.

Platform · User-level owner · Starts · Restart works after setup · Notes macOS · launchd LaunchAgent · at user login · Yes · First verified target; no administrator account required. Linux · systemd --user · at user login · Implemented; verify on your host · loginctl enable-linger is optional for running after logout and is never enabled automatically. The unit template is render-tested but has not been run on a real Linux host yet. Windows · Task Scheduler + current-user wrapper · at user logon · Template supplied; verify on Windows before production use · No administrator account required.

The generated service files contain absolute paths, one audited PATH, and no secrets — never your API keys, npm tokens, cookies or proxy credentials. By default install saves the PATH of the terminal that ran it, so Homebrew, MacPorts, Nix, asdf, Conda, Cargo and hand-installed tools all follow the same rule; --path-source minimal keeps a fixed environment and --service-path supplies an explicit one. plan --dry-run shows the final value and every warning before anything is written. Native files, logs, status and removal: user-service supervision. To check Linux or Windows on your own machine: platform acceptance.

A restart interrupts running work and does not save it. If DSH cannot list what is running, cannot verify that your service owns the current process, or was started by hand or by the desktop app, it refuses to restart at all — a web page cannot talk it into it.

LAN / non-loopback pages

Earlier DSH releases restricted non-loopback settings forms to memory-only state. DSH 0.2.1-rc.3 no longer exposes that mode field in form snapshots: the official entry-addressed form calls the settings Remote directly. Do not infer current persistence or authorization from an origin check alone; the running Host's settings policy decides whether a write is accepted.

From 0.1.2 this plugin is fully usable there anyway:

• The version/update status is fetched normally. Earlier releases gated the whole feature on connection.isLoopback === true, so a page reached through a LAN bridge (dsh-bridge, dsh-lan-proxy, …) never sent POST /api/dsh-update-status.get-status, could not open the detail panel, and showed this bundle's declared compatible release as if it were the running version. That gate is gone — the Connection RPC is authenticated and the Host route is the plugin's own.
• Preferences (sidebarEnabled, cacheTtlMinutes) keep reading and writing the ONE shared Host settings entry dsh-update-status, through the same public Remote the official settings form speaks (settings.describe / settings.mutate). Writes stay revision-fenced, and a refused write surfaces as a conflict instead of a silent overwrite. The direct channel opens only when the official form reports unavailable, so a loopback page keeps the official path and pays no extra wire read.

A LAN bridge must preserve DSH's authenticated transport and Host authorization policy. This plugin does not change bridge configuration or grant settings access; a Host refusal must be resolved by the deployment operator.

Compatibility

Current release: plugin `0.4.7` is verified against DeepSeek Harness `0.2.1-rc.3` (the current release), `0.2.1-rc.2`, `0.2.1-alpha.5`, `0.2.1-alpha.4`, `0.2.1-alpha.3`, `0.2.1-alpha.1`, `0.2.0-rc.2`, `0.2.0-rc.1`, `0.1.7-rc.2`, `0.1.7-rc.1` and `0.1.7-alpha.2`.

Which plugin version goes with which DeepSeek Harness version

Plugin · Verified DeepSeek Harness · On npm · What that version is `0.4.7` · 0.2.1-rc.3, 0.2.1-rc.2, 0.2.1-alpha.5, 0.2.1-alpha.4, 0.2.1-alpha.3, 0.2.1-alpha.1, 0.2.0-rc.2, 0.2.0-rc.1, 0.1.7-rc.2, 0.1.7-rc.1, 0.1.7-alpha.2 · latest · Removes the redundant settings menu; version status and update notices remain on by default, with details in the sidebar chip panel `0.4.6` · 0.2.1-rc.3, 0.2.1-rc.2, 0.2.1-alpha.5, 0.2.1-alpha.4, 0.2.1-alpha.3, 0.2.1-alpha.1, 0.2.0-rc.2, 0.2.0-rc.1, 0.1.7-rc.2, 0.1.7-rc.1, 0.1.7-alpha.2 · published · Verifies DSH 0.2.1-rc.3, includes maintenance and starting terminals in restart confirmation, and restores restart-storm recovery guidance `0.4.5` · 0.2.1-rc.2, 0.2.1-alpha.5, 0.2.1-alpha.4, 0.2.1-alpha.3, 0.2.1-alpha.1, 0.2.0-rc.2, 0.2.0-rc.1, 0.1.7-rc.2, 0.1.7-rc.1, 0.1.7-alpha.2 · published · Compatibility declaration for DSH 0.2.1-rc.2; no functional code changed, both READMEs were re-checked, and the published package was compared with the repository `0.4.4` · 0.2.1-alpha.5, 0.2.1-alpha.4, 0.2.1-alpha.3, 0.2.1-alpha.1, 0.2.0-rc.2, 0.2.0-rc.1, 0.1.7-rc.2, 0.1.7-rc.1, 0.1.7-alpha.2 · published · Compatibility declaration for DSH 0.2.1-alpha.5; no functional code changed, and both READMEs were re-checked for stale version numbers `0.4.3` · 0.2.1-alpha.4, 0.2.1-alpha.3, 0.2.1-alpha.1, 0.2.0-rc.2, 0.2.0-rc.1, 0.1.7-rc.2, 0.1.7-rc.1, 0.1.7-alpha.2 · published · Compatibility declaration for DSH 0.2.1-alpha.4; no functional code changed, and the panel now shows this running release as verified compatible `0.4.2` · 0.2.1-alpha.3, 0.2.1-alpha.1, 0.2.0-rc.2, 0.2.0-rc.1, 0.1.7-rc.2, 0.1.7-rc.1, 0.1.7-alpha.2 · published · Compatibility declaration for DSH 0.2.1-alpha.3; no functional code changed, and the panel now shows this running release as verified compatible `0.4.1` · 0.2.1-alpha.1, 0.2.0-rc.2, 0.2.0-rc.1, 0.1.7-rc.2, 0.1.7-rc.1, 0.1.7-alpha.2 · published · The service saves the PATH used during installation, so tools installed by any package manager stay available after DSH is supervised `0.4.0` · 0.2.1-alpha.1, 0.2.0-rc.2, 0.2.0-rc.1, 0.1.7-rc.2, 0.1.7-rc.1, 0.1.7-alpha.2 · published · Restart you can trust: the service stops instead of restarting forever, the button needs the service to really own the process, and a disabled button shows the two commands that recover it. Settings also shows when the service started `0.3.2` · 0.2.1-alpha.1, 0.2.0-rc.2, 0.2.0-rc.1, 0.1.7-rc.2, 0.1.7-rc.1, 0.1.7-alpha.2 · published · Documentation only: the version table and every past release note are now plain language. Behaves exactly like 0.3.1 `0.3.1` · 0.2.1-alpha.1, 0.2.0-rc.2, 0.2.0-rc.1, 0.1.7-rc.2, 0.1.7-rc.1, 0.1.7-alpha.2 · published · Small polish: the settings page explains Restart too, and a long job name can no longer push the buttons away. `0.3.0` · 0.2.1-alpha.1, 0.2.0-rc.2, 0.2.0-rc.1, 0.1.7-rc.2, 0.1.7-rc.1, 0.1.7-alpha.2 · published · Adds Restart to the panel, plus the one-command service setup it needs. Without that service the button stays disabled and says why. `0.2.1` · 0.2.1-alpha.1, 0.2.0-rc.2, 0.2.0-rc.1, 0.1.7-rc.2, 0.1.7-rc.1, 0.1.7-alpha.2 · published · Hiding the version chip brings DSH’s own name and fish mark back, instead of leaving the brand row blank. `0.2.0` · 0.2.1-alpha.1, 0.2.0-rc.2, 0.2.0-rc.1, 0.1.7-rc.2, 0.1.7-rc.1, 0.1.7-alpha.2 · published · One update line instead of a channel picker: the panel reports whatever version npm publishes newest, and there is nothing to configure. `0.1.12` · 0.2.0-rc.2, 0.2.0-rc.1, 0.1.7-rc.2, 0.1.7-rc.1, 0.1.7-alpha.2 · published · Adds DSH 0.2.0-rc.2 to the verified list; no code change. `0.1.11` · 0.2.0-rc.1, 0.1.7-rc.2, 0.1.7-rc.1, 0.1.7-alpha.2 · published · Declares the DSH 0.2.0 line and widens the supported range, so a newer DSH can no longer drop the plugin without a word. `0.1.10` · 0.1.7-rc.2, 0.1.7-rc.1, 0.1.7-alpha.2 · published · No more button in the collapsed sidebar rail — it did not fit there and pushed a neighbouring plugin’s icon aside. 0.1.9 · 0.1.7-rc.2, 0.1.7-rc.1, 0.1.7-alpha.2 · published · Fixes the plugin disappearing after a DSH upgrade (a leftover copy of a shared library could take it down), and the settings page now says which folder to delete. 0.1.8 · 0.1.7-rc.2, 0.1.7-rc.1, 0.1.7-alpha.2 · published · Adds DSH 0.1.7-rc.2 to the verified list; no code change. 0.1.7 · 0.1.7-rc.1, 0.1.7-alpha.2 · published · The English UI is fully English now: status messages are rendered by the browser in its own language. 0.1.6 · 0.1.7-rc.1, 0.1.7-alpha.2 · published · Adapts to DSH 0.1.7, where the plugin’s two preferences are stored as its own settings entry. 0.1.5 · 0.1.6-alpha.2, 0.1.6-alpha.1, 0.1.5-rc.1 · published · One dot carries every state (green up to date, grey checking, amber for an update), and advisory notices stop recolouring the chip. 0.1.4 · 0.1.6-alpha.1, 0.1.5-rc.1 · published · Fixes the entry for the version you are running showing as unselectable. 0.1.3 · 0.1.6-alpha.1, 0.1.5-rc.1 · published · Carries the LAN-page fix and re-verifies it on DSH 0.1.6. 0.1.2 · 0.1.5-rc.1 · never published · Removes the loopback-only restriction, so a LAN page works too. 0.1.1 · 0.1.5-rc.1 · published · The previous npm latest; on a LAN page the plugin does nothing. 0.1.0 · 0.1.2-rc.1 · published · First release.

• Which version goes with which DSH? 0.1.6–0.1.10 are for the DSH 0.1.7 line; 0.1.11 and later also declare the 0.2.0 line. DSH 0.1.7 changed how a plugin stores its settings, so on an older DSH — including 0.1.6-alpha.2 — stay on plugin `0.1.5`.
• "Verified" means that exact DSH release was tested with this build. A release that is missing from the list is shown as *unverified compatible* — a note in the panel only, which never recolours the chip — so upgrading DSH ahead of the plugin is safe to try. If a release turns out genuinely incompatible, disable or uninstall the plugin rather than editing DSH itself. (The list is kept in package.json and src/shared/types.ts, in sync by a test.)
• On npm means what dsh plugin --profile web add dsh-update-status@latest actually installs. A version that exists in this repository but not on npm is a development state, not a release.
• Match them explicitly when it matters:

dsh plugin --profile web add dsh-update-status@0.4.7   # DSH 0.2.1-rc.3, 0.2.1-rc.2, 0.2.1-alpha.5, 0.2.1-alpha.4, 0.2.1-alpha.3, 0.2.1-alpha.1, 0.2.0-rc.2, 0.2.0-rc.1, 0.1.7-rc.2, 0.1.7-rc.1 or 0.1.7-alpha.2
  dsh plugin --profile web add dsh-update-status@0.4.5   # DSH 0.2.1-rc.2, 0.2.1-alpha.5, 0.2.1-alpha.4, 0.2.1-alpha.3, 0.2.1-alpha.1, 0.2.0-rc.2, 0.2.0-rc.1, 0.1.7-rc.2, 0.1.7-rc.1 or 0.1.7-alpha.2
  dsh plugin --profile web add dsh-update-status@0.4.4   # DSH 0.2.1-alpha.5, 0.2.1-alpha.4, 0.2.1-alpha.3, 0.2.1-alpha.1, 0.2.0-rc.2, 0.2.0-rc.1, 0.1.7-rc.2, 0.1.7-rc.1 or 0.1.7-alpha.2
  dsh plugin --profile web add dsh-update-status@0.4.3   # DSH 0.2.1-alpha.4, 0.2.1-alpha.3, 0.2.1-alpha.1, 0.2.0-rc.2, 0.2.0-rc.1, 0.1.7-rc.2, 0.1.7-rc.1 or 0.1.7-alpha.2
  dsh plugin --profile web add dsh-update-status@0.4.2   # DSH 0.2.1-alpha.3, 0.2.1-alpha.1, 0.2.0-rc.2, 0.2.0-rc.1, 0.1.7-rc.2, 0.1.7-rc.1 or 0.1.7-alpha.2
  dsh plugin --profile web add dsh-update-status@0.3.2   # DSH 0.2.1-alpha.1
  dsh plugin --profile web add dsh-update-status@0.2.0   # DSH 0.2.1-alpha.1, 0.2.0-rc.2, 0.2.0-rc.1, 0.1.7-rc.2, 0.1.7-rc.1 or 0.1.7-alpha.2
  dsh plugin --profile web add dsh-update-status@0.1.12 # DSH 0.2.0-rc.2, 0.2.0-rc.1, 0.1.7-rc.2, 0.1.7-rc.1 or 0.1.7-alpha.2
  dsh plugin --profile web add dsh-update-status@0.1.11 # DSH 0.2.0-rc.1, 0.1.7-rc.2, 0.1.7-rc.1 or 0.1.7-alpha.2
  dsh plugin --profile web add dsh-update-status@0.1.10  # DSH 0.1.7-rc.2, 0.1.7-rc.1 or 0.1.7-alpha.2
  dsh plugin --profile web add dsh-update-status@0.1.9   # DSH 0.1.7-rc.2, 0.1.7-rc.1 or 0.1.7-alpha.2
  dsh plugin --profile web add dsh-update-status@0.1.8   # DSH 0.1.7-rc.2, 0.1.7-rc.1 or 0.1.7-alpha.2
  dsh plugin --profile web add dsh-update-status@0.1.7   # DSH 0.1.7-rc.1 or 0.1.7-alpha.2
  dsh