DeepSeek Harness desktop update: signed unit and DSH plugin

A DeepSeek Harness desktop update is a whole-package action: it does not let you swap a single dsh version, it replaces the Electron shell, the matching dsh runtime, Node.js and pnpm as one signed update unit that always shares one exact version (source).

If you only want the buttons and the polling cadence, that is the operational side and it lives in how to update the DeepSeek Harness desktop app. This article covers the mechanics instead: why a desktop update is always a whole package, what verifies the runtime at startup, and why upgrading dsh requires a new Desktop release. Desktop, core and plugins are three separate update layers, compared in DeepSeek Harness auto-update.

Why a DeepSeek Harness desktop update is a whole package

The smallest unit of a desktop update is not an npm package but a signed update unit, made of the Electron shell, the matching dsh runtime, Node.js and pnpm, all sharing one exact version and shipped together (source).

Break down where each part comes from and you stop thinking that updating the app equals swapping one dsh package:

That explains five common misconceptions:

1. The app is not "a shell plus your dsh" — it is an Electron shell wrapping the dsh Web UI, and dsh ships with it as a full production dependency tree rather than relying on a global install. Expect a brand-new machine to run right after installing the app, with no npm i -g first.
2. Bundled runtimes and system runtimes do not mix — dsh runs through the bundled upstream Node.js and every package operation uses bundled pnpm; the Electron Node.js, system Node.js, system pnpm and your package manager config never enter the execution path. Expect other Node versions on your machine not to skew the runtime the app uses.
3. Versions are bound, not assembled — the Electron shell and @deepseek-ai/dsh always use the same exact version, so updating the app refreshes the whole runtime. Expect the dsh version shown in settings to always match the app's own release version.
4. Web client, backend and plugin graph are verified as one batch — a release verifies the desktop shell API, web client, backend and plugin dependency graph as a single combination. Expect the app version you see to name that whole relationship, not one package's version.
5. Block reuse saves bandwidth, it does not change versions — platform update artifacts reuse unchanged data blocks to cut download size, but that reuse is file-level only. Expect reused blocks never to drift the app onto a different dsh version.

To confirm which runtime is bundled, run dsh --version (equivalent to dsh -V) to get the dsh version of that runtime (source).

What desktop-runtime.json verifies at startup

At startup the app reads resources/dsh/desktop-runtime.json from the signed resources, a manifest binding the shell version, bundled Node version, platform, architecture, shared package versions and the final file list, to confirm the runtime was not swapped or damaged (source).

You can open that manifest and check it yourself — on macOS it sits inside the app bundle under Contents/Resources/dsh/, on Windows under resources\dsh\ in the install directory. Walk through these six points:

1. Locate and print the manifest — on macOS run cat <app bundle>/Contents/Resources/dsh/desktop-runtime.json; on Windows run type <install dir>\resources\dsh\desktop-runtime.json. Expect a JSON document exposing the shell, Node and platform fields.
2. Read the runtime metadata — startup reads the manifest first. Expect the shell version, bundled Node version, platform and architecture as the base set of facts.
3. Cross-check the shell version — compare the manifest's shell version against the one shown under "Check for Updates…". Expect them to match, proving the shell was not swapped.
4. Check shared package records — the app links each built-in first-party package into the current profile with a directory symlink (a junction on Windows) and checks those records at startup. Expect first-party packages to point back into the signed resources rather than being copied into the profile or reinstalled through pnpm.
5. Confirm file integrity — release schema, shell version, target compatibility and file integrity are verified at packaging time. Expect a mismatch to surface at startup rather than midway through a run.
6. No core reinstall on first launch — the first launch does not copy core packages into profile storage or install them through pnpm. Expect the profile to hold only the external plugins you added, with core packages always coming from the signed resources.

To see the shared links for yourself, run ls -l on a profile directory (or dir /AL on Windows) to list those symlinks and junctions: Expect them to point into the signed resources — a broken link usually means the resources were edited by hand.

Why upgrading dsh requires a new Desktop release

Because runtime version selection never leaves the Desktop release: even when the shell code itself is unchanged, upgrading the dsh runtime requires shipping a new Desktop release that carries the new runtime inside the signed update unit (source).

That constraint drives four rules:

1. Do not swap the bundled dsh to "upgrade" — replacing the in-app runtime by hand breaks version consistency, because the app's dsh version follows the app. Expect the right upgrade path to be updating the app, not editing files under extraResources.
2. The CLI dsh and the desktop dsh are not the same copy — npm update -g @deepseek-ai/dsh only refreshes your global install and leaves the bundled runtime untouched. Expect dsh --version moving forward in a terminal to say nothing about the app's version, so the two must be updated separately.
3. Update artifacts may reuse unchanged blocks — to cut download size, platform update artifacts may reuse unchanged data blocks, but that reuse is file-level only. Expect reused blocks to keep the runtime on the release's chosen version rather than drifting to another dsh.
4. Release identity is a verified relationship — the desktop shell API, web client, backend and plugin dependency graph are verified together as one release, and the exact Electron-to-@deepseek-ai/dsh relationship is part of it. Expect the app version you see to be the name of that whole relationship.

Before updating, work out which layer you are actually touching: which dsh (or where dsh on Windows) shows the global entry point, npx @deepseek-ai/dsh web resolves a temporary one, and the app always runs its bundled runtime. Expect the three version tracks to stay independent, so fixing one never fixes another by accident.

Notes on the DeepSeek Harness desktop update unit

1. Treat the app as one unit — do not try to upgrade dsh or the shell alone; version binding makes them move together.
2. Do not steer the runtime with system Node or pnpm — bundled Node.js and bundled pnpm are the execution path, so changing system tools does not affect the app.
3. Plugins are a separate layer — a desktop update replaces the runtime only, so version changes for installed DSH plugins are handled separately; see what happens to DSH plugins after a desktop update.
4. Reinstall rather than hand-edit after a failed check — when the desktop-runtime.json file list no longer matches, going back to the official installer is more reliable than editing the runtime.
5. Keep the three version tracks apart — the global CLI, npx resolution and the bundled runtime are independent; when you check with dsh --version, confirm which copy it hit instead of treating one number as the whole picture.
6. Keep the current installer around before updating — the desktop app has no version pin, so holding on to the current official installer lets you reinstall or roll back directly if a check fails.

To sort out the plugin layer as well, use the built-in DSH Plugin Hub instead of tracking versions package by package: its installed list flags plugins with an available update, handles them in a click, and shows a confirmation dialog before anything changes.

Sources: DeepSeek Harness desktop README, Electron desktop packaging and updates Agent Note, DeepSeek Harness for desktop - download