DeepSeek Harness auto-update: how to keep dsh current

The dsh core has no built-in auto-update switch: to keep it current you either launch it through npx, which re-resolves @latest on every start, or schedule the update command as a system task; what actually provides automatic checking and prompting is the plugin side, through DSH Plugin Hub's check-for-updates on startup and its update badge. DSH plugins sit on that plugin side and get the prompts, while the core layer has no switch at all. This article treats the two layers separately and states the cost of each.

Two separate layers: DeepSeek Harness core auto-update and DSH plugin prompts

Auto-update in DeepSeek Harness is really two independent problems: the core is an npm global or npx temp package that needs an external mechanism to fetch the newest version, while plugins are managed by the dsh plugin channel and have built-in checking and prompting (source). Compare them:

Find out which group you are in: 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 next section applies.

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. Auto-updating the core and auto-updating plugins are different jobs: the first runs through npm and scheduled tasks, the second through market badges, and neither drives the other.
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.

Keeping the core on scheduled tasks and plugins on market prompts keeps the two 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