Updating DeepSeek Harness via proxy: DSH plugin registry

Most DeepSeek Harness update failures are filed as network problems, but network is four layers — DNS, proxy, registry and TLS — each with a different fix. Work in order: separate the layers, choose a route (mirror, proxy, internal registry), then handle slowness and hangs. DSH plugin packages use the same registry configuration, so the CLI conclusions transfer.

Separating the four layers of a DeepSeek Harness update failure

Bottom line: one manual metadata request separates all four. A response means the path works and the problem is package or version; no response means walk upward.

1. DNS: the registry hostname does not resolve ("host not found"). Try ping or nslookup on that host.
2. Proxy: resolves but will not connect (timeouts). Confirm a proxy is required, the variables are set, and the proxy itself is reachable.
3. Registry: path works but the package is missing (404, "version not found"). Switch mirrors or check whether the version synced.
4. TLS: certificate chain errors. Common behind enterprise TLS inspection; trust the enterprise root instead of disabling verification, which has a security cost.

npm config get registry
npm view @deepseek-ai/dsh version      # expected: returns a version, meaning path and registry work
# if this errors, classify it against the four layers above

Route A: use an npm mirror to update DeepSeek Harness

Bottom line: point the registry at a reachable mirror and routine upgrades work immediately. The only cost is sync delay, which affects "upgrade the instant it ships."

1. Configure at project level to avoid polluting global config:

# .npmrc
registry=https://your-mirror/

2. Verify and update:

npm config get registry
npm i -g @deepseek-ai/dsh@0.2.0-rc.2
dsh --version

3. When told the version does not exist, check the mirror's version list first. If the version is absent, it has not synced — wait, or use the official registry for that one install.
4. Two ways to switch temporarily: a command-line registry flag or a temporary environment variable. Restore afterwards; do not let temporary configuration become permanent.

Route B: update DeepSeek Harness through a proxy

Bottom line: when a proxy is required, set both variables to the same reachable address; when it is not, unset them. Leaving them empty is the most common trap.

1. Set the proxy correctly:

export HTTPS_PROXY=http://127.0.0.1:7890
export HTTP_PROXY=http://127.0.0.1:7890
env | grep -i proxy        # expected: both variables hold addresses, with no empty entries

2. Remove stray empty variables:

unset all_proxy ALL_PROXY 2>/dev/null || true
env | grep -iE '(proxy)='  # confirm no "xxx=" empty values remain

3. Why empty breaks: an empty string is treated as a real value and can trigger cleanup logic reserved for proxy scenarios, so children connect directly with no warning — only the child fails to fetch.
4. Do not misconfigure proxy and private registry together: when both are in play, the proxy must be able to reach the private registry, or internal traffic is routed outward for no reason.

Route C: internal registry with scheduled sync

Bottom line: turn "can we update" into "did the sync job run." One internet-connected machine pulls the CLI and plugin list; internal machines install only from there.

1. Designate one syncing machine with internet access; everyone else reads the private registry.
2. Sync three categories: the CLI package, the DSH plugin packages you use, and their dependencies.
3. Drive sync from a manifest: decide the plugin set in DSH Plugin Hub, write it into the sync script, and sync in one pass.
4. Spot-check after syncing by installing one plugin on an internal machine — more reliable than reading sync logs.
5. Document how the syncing machine reaches the internet (direct, mirror, proxy). When updates break, check that first.

Three network-layer checks for slow or stuck DSH plugin updates

Bottom line: this article only covers the network layer — slow means source quality, stuck means which step is waiting. Leftover processes, a full disk and cache locks are out of scope here.

1. Read the last output line: resolution, download or extraction tells you whether it is source, proxy or TLS.
2. A/B the registry: run the same command against a responsive source. Much faster means the original source is poor.
3. Time-box the run to separate slow from stuck:

timeout 600 npm i -g @deepseek-ai/dsh@0.2.0-rc.2
# expected: exits non-zero on timeout, distinguishing "always slow" from "truly stuck"

4. Non-network causes go to the other guide: leftover processes, full disks, cache locks and desktop hangs are covered in troubleshooting stuck dsh updates.

DSH plugin troubleshooting behind proxies

Bottom line: when the CLI updates but plugins do not, the plugin packages are almost certainly missing from your source. Sync first, then discuss network.

1. Note which layer 404'd: CLI or plugin decides whether you fix the source or the sync manifest.
2. Clear empty proxy variables first, or every later conclusion is unreliable.
3. Restart the service after updating; a long-running dsh web keeps the old version.
4. Keep one entry point: global and npx together produce "updated but not in effect" (see npx versus global version drift).
5. Expect mirror sync delay and switch to the official registry when you truly need the newest release.
6. Repair status, stated honestly: each item follows npm registry and .npmrc mechanics plus the official CLI upgrade notes. Registry addresses and proxy settings are environment-specific; confirm flag names with dsh --help.

If the update merely stalls or runs slow without mirror or proxy constraints, see troubleshooting stuck dsh updates.

Sources: apps/cli/README.md, npm Docs · registry, apps/desktop/README.zh.md.