dsh updated but version unchanged: PATH and cache checks

When dsh says it updated but the version did not change, separate three layers: the package installed on disk, the command PATH resolves, and the process currently running. DSH plugins and every DeepSeek Harness plugin are judged through the same PATH and cache mechanics, with their own entry point described at the end. Most of the time it is an unrestarted service; the rest is usually a second installation, a PATH ordering problem, an nvm-switched Node, or a stale command hash cache. Work through them in that order.

Three layers behind an unchanged DeepSeek Harness version: package, command, process

"Version unchanged" means three completely different things: the package never got installed, it was installed but the command resolves to a different copy, or the command is new while the running process is still old (source). Match your symptom first:

1. See where the package landed — run npm ls -g @deepseek-ai/dsh. Expect: the global version npm recorded.
2. See which copy the command uses — run which dsh (Windows: where dsh). Expect: the path actually executed; compare it against the global directory from step 1.
3. See which copy the process uses — restart dsh and run dsh --version again. Expect: only if it still disagrees do you need to dig into PATH and caches.

The most common cause: the DeepSeek Harness service was not restarted

Updating writes new files to disk, but a dsh process that is already running still holds the old code, so the version only changes after the process restarts, which is the single most frequent cause of "it updated but the version did not change" (source). Three steps:

1. Stop the current process — press Ctrl+C in the terminal running dsh; if you host it as a background service, restart that with systemctl --user restart dsh (Linux) or launchctl kickstart -k gui/$(id -u)/org.dsh.web (macOS). Expect: lsof -i :3080 shows no listener first, then a listener again after the restart.
2. Confirm no stray process remains — run pgrep -af dsh. Expect: only the one you just started; several means an old process still holds the port.
3. Verify the version again — run dsh --version. Expect: the new version. If it is still old, keep going into PATH.

An easily missed detail: the browser tab belongs to the old process, so refresh it after restarting (a hard refresh if needed), otherwise the behavior you observe may still be from before.

DSH plugin PATH and multiple installs: the update landed on another copy

When several dsh installs exist on one machine, npm may have updated a different copy than the one you execute, so the version appears unchanged (source). Four steps:

1. List every match — run which -a dsh (Windows: where dsh). Expect: multiple lines, where the first is what the command runs; more than one line means several installs.
2. See which directory npm updated — run npm ls -g @deepseek-ai/dsh and npm root -g. Expect: you can tell at a glance whether the global directory matches the copy resolved in step 1.
3. Check the active Node version — run node -v and npm prefix -g. Expect: if you use nvm, each Node version has its own global directory, so updating under one does not affect another.
4. Reinstall on the right copy — switch to the Node version you actually use and run npm install -g @deepseek-ai/dsh@latest. Expect: npm root -g and which dsh point to the same area, and dsh --version changes accordingly.

The guiding principle: rather than updating repeatedly across several installs, keep only one. Remove the extra global installs, or manage Node uniformly with nvm, so "updated but unchanged" stops recurring.

DeepSeek Harness command hash cache and npx cache

Interactive shells cache command-to-path mappings, so after a program is replaced or moved the cache may still point at the old path; if you run through npx, you may also hit a stale copy under ~/.npm/_npx (source). Three cleanup steps:

1. Clear the shell cache — run hash -r (works in bash and zsh), or rehash in zsh. Expect: which dsh now returns the real current path.
2. Clear the npm and npx cache — run npm cache clean --force. Expect: the next npx @deepseek-ai/dsh@latest re-downloads instead of reusing a stale copy.
3. Verify again — run which dsh, dsh --version, and npm view @deepseek-ai/dsh version in order. Expect: all three agree; if the last one is lower, continue to the next section.

DeepSeek Harness mirror lag: mistaking "not synced yet" for "update did not work"

npm view and npm outdated read cached data from your current source, and a mirror can lag behind official releases, which makes it look like there is nothing to update (source). Three checks:

1. See the current source — run npm config get registry. Expect: the registry address, telling you whether it is a mirror.
2. Query the official source directly — run npm view @deepseek-ai/dsh version --registry https://registry.npmjs.org. Expect: compare with the previous result; a higher number here means mirror lag, not a failed update.
3. Switch or override the source when needed — if you are stuck on a mirror, pass --registry to reinstall from the official source once. Expect: the version updates to the newest stable release on the official source.

Five reminders apply throughout:

1. Restart before suspecting a failed update: an unrestarted process is the most common cause, so do not reinstall repeatedly as a first reaction.
2. Do not update back and forth between installs: touching one while verifying another will never match; consolidate to a single install first.
3. Write down the path which dsh returns: it is the only reliable evidence of which copy the command uses.
4. The first start after clearing caches is slower: re-downloading is normal, so do not treat it as a new fault.
5. If behavior is wrong after the version did change: that is a compatibility issue on a different path; see DSH plugin incompatible after a DeepSeek Harness update.

Once the core version is verified, plugin state is a separate check: DSH Plugin Hub is the official plugin market built into DeepSeek Harness, and its installed list shows each plugin's current version and update badge. When the version number is correct but the behavior still does not match expectations, confirm on that page whether the relevant plugin really reached the new version, instead of mistaking an un-updated plugin for a core update that did not take effect.

Sources: npm Docs - npm prefix, npm Docs - npm ls, GNU Bash Reference Manual (hash), deepseek-ai/deepseek-harness GitHub repository