npx @deepseek-ai/dsh web offline: DSH plugin and mirrors

Running DeepSeek Harness with npx @deepseek-ai/dsh web offline is really one question: where does the package come from? npx assumes a reachable registry, so prepare a private registry, a warmed cache, or package files carried in — each maps to a different network condition. One trap deserves warning up front: empty proxy variables are treated as real values, so children silently connect directly.

Three DeepSeek Harness "no network" situations

Bottom line: fully offline means cache warm-up, an intranet source means a private registry, proxy-only means fixing proxy variables. They are not interchangeable, and mixing them hides the real failure.

Option A: private registry (best for enterprises)

Bottom line: point the registry at your private source and both npx and plugin installs follow. The prerequisite is that the CLI and every plugin package you need — with dependencies — are already synced there.

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

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

2. Verify it took effect:

npm config get registry
# expected: your private registry, not the public default

3. Install the CLI, then plugins one by one:

npx -y @deepseek-ai/dsh@0.2.0-rc.2 web --port 3080
# expected: resolves from the private source; a 404 means that version is not synced

4. Sync the plugin set up front: decide which DSH plugin packages you need in DSH Plugin Hub, then sync that batch with dependencies in one pass rather than one plugin at a time.
5. Document the available set: list which packages and versions exist in the source so colleagues stop guessing.

Option B: cache warm-up (when you can only move a cache)

Bottom line: download into the cache on a connected machine, move the cache directory, and reuse it offline. No registry required — good for one-off deliveries and a few machines.

1. Warm the cache on the connected side:

npm cache add @deepseek-ai/dsh@0.2.0-rc.2
npm cache verify
# expected: the package appears in the cache directory

2. Locate and move the cache directory (confirm the path with npm config get cache).
3. Run offline against the same cache:

npx --offline -y @deepseek-ai/dsh@0.2.0-rc.2 web --port 3080
# expected: starts without network access; missing packages fail loudly instead of hanging

4. Warm plugins too, or only the CLI will start offline.
5. The trade-off: caches tolerate version differences but not architecture differences — native modules still need compiling on the target machine.

Option C: carry package files in (most reliable fallback)

Bottom line: pack the tarballs, copy them in, install from local files. When the network is fully isolated, this is the dependable route.

1. Pack on the connected side:

npm pack @deepseek-ai/dsh@0.2.0-rc.2
# expected: a file such as deepseek-ai-dsh-0.2.0-rc.2.tgz appears

2. Install or run locally on the offline side:

npm i -g ./deepseek-ai-dsh-0.2.0-rc.2.tgz
dsh --version

3. Pack DSH plugin packages the same way.
4. Keep a manifest of package names, versions and counts, and reconcile it at handover — this scenario punishes assumptions about completeness.

DeepSeek Harness registry and proxy variables

Bottom line: two rules — set the ones you need correctly, unset the ones you do not. Leaving them empty is worse than setting them wrong.

1. Set the proxy only when needed (replace with your address):

export HTTPS_PROXY=http://127.0.0.1:7890
export HTTP_PROXY=http://127.0.0.1:7890

2. Unset rather than blank:

unset HTTPS_PROXY HTTP_PROXY
env | grep -i proxy      # expected: no output, not "xxx_PROXY="

3. Why empty breaks: an empty string is passed to children as a real value and can trigger cleanup logic reserved for specific proxy scenarios, so children silently bypass the proxy. On an intranet this looks like "the proxy is configured but nothing downloads," with nothing visibly wrong on the host.
4. Sweep the environment once: run env | grep -iE '(proxy|no_proxy)=' and fix empty entries.

Verifying the DeepSeek Harness mirror actually works

Bottom line: the hardest proof is to cut public access and run again; the softest is to read the address in config and logs. Do both.

1. Read the effective config: npm config get registry plus npm config list, checking for higher-priority overrides.
2. Watch the request host in install output — your private domain is correct; the public domain means the configuration did not apply.
3. Block public access and retry (conclusive).
4. Force cache-only with --offline to confirm the warm-up is complete.
5. Call a plugin function once — a running CLI does not prove the plugin works.

DSH plugin troubleshooting offline

Bottom line: offline failures are almost always "the package is not there," not "the command is wrong." Check presence first.

1. List before acting: write down CLI and plugin package names with versions, then verify each after syncing.
2. Separate CLI-missing from plugin-missing: the 404'd package name tells you whether to fix the source or the cache.
3. Eliminate empty proxy variables or every network check lies.
4. Plan for native dependencies: prebuilt artifacts do not carry across architectures.
5. Do not retry in a loop — retries do not create packages.
6. Repair status, stated honestly: these options follow npm's registry and npx mechanics; confirm DeepSeek Harness and plugin package names and versions against what you actually use, since private registry setups vary by organization.

If the offline target is a plugin package rather than the CLI, see installing DSH plugin offline.

Sources: npm Docs · registry, npm Docs · npx, npm @deepseek-ai/dsh.