DeepSeek Harness auto-update: desktop, CLI and plugin layers

Auto-update in DeepSeek Harness has three layers: the desktop app has a built-in update check and also offers Check for Updates, but downloading and installing both wait for you; the command-line core has no update switch, so you either launch it through npx, which re-resolves @latest on every start, or schedule the update command as a system task; the plugin side gets its prompts from DSH Plugin Hub's check on startup and its update badge. DSH plugins sit on that plugin side and get the prompts, while the command-line core has no switch at all. This article treats the three layers separately and states the cost of each.

Three separate layers: desktop updates, dsh core updates and DSH plugin prompts

Auto-update in DeepSeek Harness is really three independent problems: the desktop app is an Electron shell with a built-in update check and a manual check in its menu, the command-line core is an npm global or npx temp package that needs an external mechanism to fetch the newest version, and plugins are managed by the dsh plugin channel with built-in checking and prompting (source). Compare them:

Find out which group you are in: if you installed the desktop app, manage updates in its app menu and read the next section; on the command line, run npm ls -g @deepseek-ai/dsh. Expect: a version means a global install, so follow the scheduling section; (empty) while you normally start with npx means the npx section applies.

The desktop app checks for updates itself: built-in polling and Check for Updates

The desktop app is the only layer with a built-in update check: it queries a fixed update channel asynchronously on startup and polls on a roughly 10 minute baseline, with ±20% jitter and backoff to one hour after failures; an automatic check never pops up and never downloads an installer, so a new release first shows as an update-available state and the download starts only once you pick it; you can also click Check for Updates in the app menu at any time (source). Three steps to confirm you are not behind:

1. Read the current version — open the first app menu item, About DeepSeek Harness. Expect: a native panel showing the app icon, product name and the currently installed release version.
2. Trigger a check by hand — click Check for Updates in the app menu. Expect: feedback covering checking, failure or up-to-date with the installed version number; a newer release moves into a downloadable state.
3. Confirm the CLI follows along — if you installed the dsh command that the desktop app offers, open a new terminal and run dsh --version. Expect: the same version as the desktop app, because that command reuses the runtime installed by the desktop app and changes with it.

Why the desktop app can do this and the CLI cannot: the desktop version and @deepseek-ai/dsh always use the same exact version number, so shipping a new dsh means shipping a new desktop release, and the app carries its own update channel to move itself onto that release. The command-line core is just an npm package with no resident process to do the same. For the mechanics of updating the app and pairing it with the CLI, see How to update the DeepSeek Harness desktop app.

Least effort for DeepSeek Harness: start it through npx and resolve the latest

npx has no resident install to update, so it resolves the package against @latest on every run, which is effectively an update on every start with no extra configuration (source). Three steps to make it routine:

1. Pass the latest tag when starting — run npx -y @deepseek-ai/dsh@latest web. Expect: npx resolves against latest and runs, with -y skipping the install prompt.
2. Confirm you really got the newest — in another terminal compare npm view @deepseek-ai/dsh version with dsh --version. Expect: they match, proving this start used the newest stable release.
3. Clear the cache if you suspect a stale copy — run npm cache clean --force and repeat step 1. Expect: it re-downloads; npx keeps temporary installs under ~/.npm/_npx.

State the trade-off plainly: each start may involve a download check, which shows up as slow startup on a poor network. If you already installed globally with npm and set up autostart, do not mix in npx as well, or the two setups will run different versions and mislead your troubleshooting.

Auto-updating a global DeepSeek Harness install: schedule the command as a system task

A global install has no "resolve latest on start" opportunity, so the right approach is to put the update command on a system schedule and let the OS run it daily; the update itself is fast, and the real cost is restarting the resident service afterwards (source). On three platforms:

1. macOS: schedule with launchd — create ~/Library/LaunchAgents/org.dsh.update.plist, use StartCalendarInterval to declare when it runs, and set ProgramArguments to /bin/sh -c "npm install -g @deepseek-ai/dsh@latest", then load it with launchctl bootstrap gui/$(id -u) <plist>. Expect: it runs on schedule, with output captured by StandardOutPath.
2. Linux: schedule with a systemd timer — create ~/.config/systemd/user/dsh-update.service (ExecStart=/usr/bin/npm install -g @deepseek-ai/dsh@latest) and dsh-update.timer (OnCalendar=daily, WantedBy=timers.target), then run systemctl --user daemon-reload && systemctl --user enable --now dsh-update.timer. Expect: systemctl --user list-timers shows the next run.
3. Windows: schedule with Task Scheduler — create a task with a Daily trigger at a fixed time, and use the full path to npm.cmd as the program with install -g @deepseek-ai/dsh@latest as arguments. Expect: it runs on schedule, and the last run result confirms success.
4. Restart the resident service after the scheduled run — if you host it as a background service per DeepSeek Harness autostart, restart that service so the process picks up the new version. Expect: dsh --version reports the new version.

Decide one thing first: auto-update means the service may change version without you knowing. If you depend on a specific version's behavior, skip scheduled updates and upgrade manually after a release notification.

How to learn about a new DeepSeek Harness release immediately

If you would rather be notified than auto-upgrade, three queries and one subscription cover it (source). In order:

1. See the gap — run npm outdated -g --depth=0. Expect: when the package is listed, the Current and Latest columns show what you run versus what is available; no output means you are current.
2. Query the newest on the source — run npm view @deepseek-ai/dsh version. Expect: the newest stable release on the source; if it looks older than announcements, check npm config get registry for a lagging mirror.
3. Subscribe to releases — on the deepseek-ai/deepseek-harness repo page choose Watch, then Custom, and tick only Releases. Expect: one GitHub notification per release, without noise.
4. Read the changelog before upgrading — confirm what changed instead of following blindly. See How to check the dsh version and read the changelog.

DSH Plugin Hub plugin-side checking: startup comparison and the update badge

Plugins never upgrade silently, but they do prompt: DSH Plugin Hub has check-for-updates on startup, which compares catalog data against installed versions and shows an update badge at the end of a row when a newer version exists (source). Three steps:

1. Turn the check on — open the Settings page and confirm check-for-updates on startup is enabled. Expect: a version comparison happens on each start.
2. Read the installed list — open the Installed page and look for rows carrying the update badge. Expect: those are the plugins with a newer version available.
3. Upgrade one by one — click the badge and confirm in the dialog. Expect: the plugin is upgraded in place; for several at once, follow the batch approach in How to batch update DSH plugins.

Why plugins are not fully automatic: an in-place upgrade replaces code that is currently loaded, and dsh usually needs a restart before it takes effect, so a silent run would lead people to conclude "it updated but nothing changed". The market leaves that final confirmation to you.

Five reminders apply throughout:

1. The three layers never drive each other: the desktop app checks for updates on its own, the core runs through npm and scheduled tasks, and plugins go through market badges, so no layer updates another along the way.
2. Give scheduled updates a log: otherwise a failure passes silently and all you see later is that the version never changed.
3. Do not schedule updates on an unattended service and walk away: a new release can change how plugins load, so someone should confirm it still starts.
4. A mirror affects your sense of whether an update exists: npm view reads whatever the source has cached, so check npm config get registry before concluding.
5. Back up before upgrading: for what survives an upgrade and how to back up, see Will updating DeepSeek Harness lose my config.

Managing the desktop app in its menu, the core on scheduled tasks and plugins through market prompts keeps the three from being confused. DSH Plugin Hub is the official plugin market built into DeepSeek Harness: its Settings page manages check-for-updates on startup along with the npm mirror and proxy channel, while the installed list marks plugins with newer versions so a single confirmation upgrades them in place, with no need to query each one from the command line.

Sources: npm Docs - npx, Apple developer documentation (launchd), systemd documentation - systemd.timer, dshplugin/dsh-plugin-hub GitHub repository