DeepSeek Harness desktop vs CLI updates: DSH plugin data

DeepSeek Harness desktop and the CLI are two separate update tracks: the CLI updates through npx, npm or source, the desktop app updates through a whole signed update unit, and neither upgrade pulls the other along. They share supported product data under $DSH_HOME, but never executables, plugin activation, lockfiles or node_modules (source).

Many people assume that updating the CLI must have made the desktop app new as well, then waste time when the versions disagree. Why a desktop update is a whole package is covered in is a DeepSeek Harness desktop update a whole-package upgrade. This article is specifically about the relationship between the two tracks: what runs separately and what is genuinely one copy.

DeepSeek Harness desktop and CLI are two update tracks

The desktop app and the CLI each maintain their own executable layer with completely different update methods, and upgrading one never drags the other along (source).

Lay the two tracks out by what they update:

Three conclusions:

1. The CLI track — update dsh via npx, npm or a source build. Expect the new dsh to appear in the CLI environment only, leaving the app untouched.
2. The desktop track — update through the in-app updater or a fresh install, replacing the whole signed update unit. Expect the new dsh to ride along with the app, leaving the CLI environment untouched.
3. Versions never pull each other — the dsh bundled in the app is always the same exact version as the published @deepseek-ai/dsh. Expect the app version to track the desktop release, regardless of what you installed from the CLI.
4. Three dsh versions can coexist on one machine — a global npm install, an npx-resolved copy and the app's bundled runtime are independent. Expect which dsh and the app's "Check for Updates…" to legitimately report different versions; that is not a fault.
5. Keeping both current means updating both — no single command refreshes both tracks. Expect to treat "update the CLI" and "update the app" as two tasks, each verified on its own.

What the two tracks share: product data under $DSH_HOME

Supported product data such as sessions, settings, credentials and tasks lives under the shared $DSH_HOME, so the desktop app and the CLI read the same copy (source).

Know the shared boundary:

1. Sessions are shared — both sides read session data from the same $DSH_HOME. Expect a session you ran in the CLI to be visible on desktop.
2. Settings and credentials are shared — they live in the shared directory too. Expect a change on one side to apply to both, with no double configuration.
3. Tasks are shared too — supported product data all lives under this same root. Expect a task recorded on one side to be visible on the other.
4. The default path is ~/.dsh — with no environment override, $DSH_HOME is ~/.dsh. Expect to confirm in one place that both sides read the same data.
5. Confirm both sides point at one root — run echo "$DSH_HOME" (an empty result means the default ~/.dsh), then ls "$DSH_HOME". Expect to see profiles, sessions and settings, proving the sharing happens at this layer.

What the two tracks never share: executables, plugin activation, profile exclusivity

Executables, plugin activation, lockfiles and node_modules are never shared, and Electron takes a single-instance lock before touching any profile and holds profiles/desktop exclusively, so the CLI may not start or modify that profile (source).

Five hard boundaries:

1. Executables are not shared — the app ships dsh as a full production dependency tree and never reads a globally installed dsh. Expect a CLI upgrade to leave the app's dsh version completely unchanged.
2. Plugin activation and dependencies are not shared — plugin activation, lockfiles and node_modules are independent, and the app installs plugins into its own profile with bundled pnpm. Expect the app and CLI plugin lists on one machine to differ freely.
3. The profile is exclusive — profiles/desktop is held by the app, and the CLI cannot start or modify it. Expect CLI attempts to touch the desktop profile to hit this boundary, which is the isolation working as designed.
4. Lockfiles are not shared either — the CLI and the app hold their own package transaction locks and never wait on each other. Expect the app running to have no bearing on updating dsh from the CLI, and vice versa.
5. Check the boundary with a read-only command — ls -l "$DSH_HOME/profiles" shows which profiles exist, with the app's one named desktop. Expect to confirm the app only touches desktop while the web, headless and other profiles you manage stay separate.

Notes on using the DeepSeek Harness desktop app and CLI together

1. Do not expect one update to bring the other along — to make both current, update each track.
2. End CLI commands before updating the app — the installer does not coordinate with a running command, so wrap up first.
3. Install plugins per environment — the app and CLI do not share plugins, so do not assume a plugin exists on the other side; see how to update DSH plugins per profile.
4. Check which side a version error comes from — the two tracks may legitimately differ, so confirm whether the error is desktop or CLI before debugging.
5. Keep the three dsh versions apart — the global npm install, npx resolution and the bundled runtime are independent, and dsh --version reports only one of them, so do not judge everything from a single number.
6. Data is shared, but do not write from both sides — $DSH_HOME is one copy, yet the app exclusively owns profiles/desktop; leave changes to that profile to the app instead of a shell.

To manage plugins on both tracks, use the built-in DSH Plugin Hub instead of switching to the terminal: its installed list shows the DSH plugins and update status for the current environment, changes happen behind a confirmation dialog, and it beats comparing versions on each side.

Sources: DeepSeek Harness desktop README, DeepSeek Harness CLI README