DeepSeek Harness reinstall still runs old dsh: three caches

DeepSeek Harness reinstall finished cleanly, the terminal said the latest version was installed, and dsh --version still printed the old number. That contradiction turned into an afternoon of forensics, because three different residue sites can each answer the command before the new install does. The story below follows the PATH binary, the npx cache and the global package in the order we found them.

The DeepSeek Harness reinstall that changed nothing

The reinstall reported success while the terminal kept answering with the version I had just replaced.

The install log looked textbook: packages resolved, scripts completed, no warnings worth reading. I ran the version command and got the same old number, then reinstalled a second time to be sure. The same log appeared, followed by the same number, which ruled out a one-off bad download. Nothing in the output said where the command was actually coming from.

The whole episode started when a DeepSeek Harness plugin update refused to load, which made a stale CLI look like the obvious culprit. I had assumed the update path was linear: install the new version and the old one disappears. That assumption was wrong in three separate places, and each place had its own way of winning the lookup. The rest of the afternoon was spent following the command instead of reinstalling it.

Scene one: an old DeepSeek Harness binary on PATH

The first residue was a binary that the shell found before the new install.

which -a dsh printed more than one path, which was the first concrete sign that the shell had a choice. The earliest match was a symlink in /usr/local/bin that pointed into an old source checkout I had forgotten about. The new install lived under a versioned directory that came later in PATH, so it never got a chance. A shell started before the change could also keep a cached path, which made the confusion worse.

I removed the symlink rather than the directory, because the checkout still held notes and a profile I wanted. Then I refreshed the shell and checked the order again. The first match moved to the new install, and the version output changed with it. Keeping the data directory also meant I did not have to rebuild the plugin environment from scratch.

Scene two: the npx cache serving an old DeepSeek Harness

The second residue lived in the npx cache, which happily served a version I thought I had replaced.

My launcher used npx @deepseek-ai/dsh without a version, and npx resolves that against its local cache before going back to the registry. The cache still held the build from an earlier trial, so the launcher kept starting the old code even after the global command was clean. The cache also carried DSH plugins fetched during that trial, which made the old environment look complete. A successful start told me nothing about which copy had started.

Pinning the exact version in the launcher proved the new package could run. I then cleared the cache and ran the unpinned command again, comparing the reported version with the pinned one. When both agreed, the second residue was gone. The launcher now records the version explicitly, so a future cache surprise cannot silently win.

Scene three: a global DeepSeek Harness install left behind

The third residue was a global install that survived a local uninstall and stayed first on the path.

npm ls -g --depth=0 showed the package installed at the global prefix, with a version older than the one I wanted. The earlier uninstall had cleaned a project-local copy and reported success, which is technically true and practically misleading. A global copy is visible everywhere, so it can answer a command in a directory that has no local install at all. That is exactly what happened here.

I uninstalled the global package, confirmed the directory no longer held it, and reinstalled the version I intended to run. The old global copy had also been loading DSH plugins from a path that no longer existed, which explained a few warnings I had been ignoring. After the reinstall, the warnings disappeared along with the old version. The global prefix was now a known quantity instead of a hidden fourth install.

Proving which DeepSeek Harness command actually runs

The only proof that matters is which command runs and which version it reports.

I stopped trusting install logs and started collecting three facts at once: every matching path, the version the shell actually executes, and what the global package list contains. The command below collects those facts in one pass. It does not change anything, so it is safe to run before deciding what to clean. The DSH Plugin Hub was useful for the plugin side, but it could not tell me which binary the shell would run.

which -a dsh
dsh --version
npm ls -g --depth=0

The read-back only counts when the three facts agree. I ran the verification in a fixed order so that a stale shell could not hide a change. Each check had to pass before I moved to the next one:

1. Confirm every path returned by which -a dsh and note which one comes first.
2. Run dsh --version in a fresh terminal and compare it with the intended release.
3. List global packages and check for an older copy at the global prefix.
4. Start the interface once and confirm it opens without the old-path warnings.
5. Run dsh plugin list and check that the expected DeepSeek Harness plugin entries load.

What I would do differently next time is write these three locations down before reinstalling anything. PATH, the npx cache and the global prefix are independent, and fixing one says nothing about the other two. A reinstall is not a cleanup; it is a new copy added to a search order that may still prefer an old one. The version read-back is the only moment the terminal tells the truth.

Sources: deepseek-harness CLI README, npm @deepseek-ai/dsh, DeepSeek Harness quickstart.