Update npx DeepSeek Harness: DSH plugin @latest, two caches

Getting an npx-run DeepSeek Harness onto the latest build comes down to pinning @latest explicitly plus clearing the right cache when needed: npx has no resident install entity and resolves the package by tag on every run, but it can hit an old copy in ~/.npm/_npx or ~/.npm/_cacache, so simply rerunning is not always the same as upgrading (source). This article works through two directions — why it keeps running an old build, and how to make sure every run lands on the newest — and touches the npx-vs-global relationship in one sentence.

DSH plugin overview: tell npx apart from a global install first

Before touching anything, confirm which kind you are running: a global install has an entity to update, npx does not. One command tells you:

npm ls -g @deepseek-ai/dsh

Expected: output means it is a global install; output of (empty) while you normally start with npx @deepseek-ai/dsh means you are in the npx case. This article focuses only on the npx case and how to land on the newest build each time; the global npm path and the difference between the two are summed up in one sentence near the end, and the full upgrade path is in the DeepSeek Harness upgrade tutorial.

DSH plugin view: why npx mode never seems to update

In npx mode there is no such thing as an "installed version", yet it does not always pull the latest — the trouble is resolution and caching. Break it into three layers:

1. No resident install — npx is a temporary executor: the package is downloaded to a temporary directory and then run, rather than staying in the global node directory as a global install does, so there is no target for npm update -g to act on. Expected: you understand that the "update" route does not apply to npx.
2. Resolved by tag each run — every run re-resolves the package, by the latest tag by default; that should mean "always newest", but the next layer discounts it. Expected: you know that in theory it is "resolve once per run".
3. May hit the cache, in fact two layers of it — npx places downloaded packages in ~/.npm/_npx (its temporary run environment), while npm's own download cache lives in ~/.npm/_cacache; either can make you reuse an old copy (source). Expected: you realize the real source of "it feels stuck on an old version" is the cache, not a typo in your command.

To summarize: npx does not "never update", it updates depending on whether that run's resolution lands on the newest. To get the newest reliably, use both hands: pin the tag explicitly and clear both cache layers when needed; for what each layer holds and how to tell them apart, see the npx version cache mechanism.

There is a second reason the confusion lingers: the two lines look identical on the command line. Whether you typed a global dsh or npx does not change what the terminal prints, so the only way to tell them apart is to know which one your shell resolves first. Checking with the npm ls command takes a second and settles it; guessing from behaviour alone is what sends people down the wrong fix, cleaning caches that were never the problem.

How to get the latest DSH plugin build: @latest and dist-tag

The standard move is to pin @latest explicitly, and dist-tag decides which version it resolves to. Four steps:

1. Check the latest version on the registry — run npm view @deepseek-ai/dsh version. Expected: it prints the latest stable version on npm; note it for later.
2. Start with the latest tag pinned — run npx -y @deepseek-ai/dsh@latest web. Expected: npx resolves against the latest tag and runs; -y skips the install confirmation prompt.
3. Clear both cache layers when you suspect a stale hit — first run npm cache clean --force to clear the npm download cache ~/.npm/_cacache, then run rm -rf ~/.npm/_npx to clear the npx temporary run environment, then rerun the previous step. Expected: npx re-resolves and re-downloads, running the latest version; the two directories are independent, so clearing only one often changes nothing.
4. Confirm the version actually running — run npx @deepseek-ai/dsh@latest --version, or read the version line in the startup log. Expected: the output matches the number noted in step 1, proving this run really is the latest.

One easy trap: mistaking a stale browser tab for "not updated". The web interface caches too, so even when the command line is already newest, the page may still show old content — do a hard refresh before judging.

Checking the version after switching a mirror

A mirror lags the official registry, so when npm view reports an old version, verify against the official source before concluding anything. Three steps:

1. See where the source points — run npm config get registry. Expected: it prints the current registry; a domestic mirror such as npmmirror usually lags the official source by minutes to hours.
2. Verify against the official source — run npm view @deepseek-ai/dsh version --registry https://registry.npmjs.org. Expected: it prints the latest stable version on the official registry; when it disagrees with the mirror, trust the official source.
3. Tell latest from a prerelease tag — run npm view @deepseek-ai/dsh dist-tags. Expected: latest points at the newest stable release, while a prerelease tag such as rc (if the maintainer has published one) points at a candidate; @latest only resolves to latest and will not hand you the candidate, so trying one requires writing that tag explicitly.

Three forms: newest, pinned, prerelease

The same npx command switches between "newest, pinned and prerelease" behaviour just by changing the package suffix. Pick by scenario:

Before pinning, confirm the version number really exists on the official Releases page or npm package page rather than writing it from memory; likewise, confirm the maintainer has actually published the tag before trying a prerelease. None of the three forms touches the global version installed on your machine — switching only affects that one run (source). Reach for @latest day to day, pin a version when you need a fixed environment, and switch between them freely.

DSH plugin and the global install (one sentence)

npx and a global install are two lines that do not affect each other: the former re-resolves by tag each run with no entity to update, while the latter goes through npm update -g or npm install -g @deepseek-ai/dsh@latest. That difference already has its own tutorial, so it is not repeated here — see the npm update dsh tutorial; if you use both, each runs its own version, so when debugging "why is it still old" first confirm which line the command you typed actually took.

One more thing often confused: updating the DeepSeek Harness core is not the same as updating a DSH plugin — plugins are managed through the dsh plugin channel and upgraded with dsh plugin --profile web update, a different maintenance path (source).

Notes and limits for using DSH plugins

Keep core and plugin updates apart, and follow these points. Item by item:

1. Do not drop @latest: in the npx case, omitting @latest risks hitting a cached old version — writing it in full is safer.
2. Think of two separate lines: npx and a global install update independently; do not assume updating one changes the other.
3. Update core and plugins separately: the core goes through npx / npm, plugins go through dsh plugin update — do not merge them into one problem.
4. Clear both cache layers: npm cache clean --force clears only ~/.npm/_cacache; the npx old copy lives in ~/.npm/_npx, so remove it separately with rm -rf ~/.npm/_npx — do both for a thorough clear.
5. Watch for a lagging mirror: when npm view reports an old version, check npm config get registry and, if needed, verify with a direct --registry https://registry.npmjs.org connection.

Once the core is updated, do not forget the plugin side — rather than typing the npx command by hand each time and remembering the tag and cache steps, let DSH Plugin Hub, the official community market for DeepSeek Harness at https://dsh-plugin.org/, manage plugin updates after a restart: click update on each installed row with an update badge, and the confirmation dialog shows the new version before reinstalling in place, so you never again mix up a core that was not updated with a plugin that was not updated.

Sources: npm Docs - npx, dsh CLI README, deepseek-ai/deepseek-harness GitHub repository.