dsh plugin market not loading? Proxy, registry and 403 fixes

Don't reinstall DSH when the dsh plugin market won't open — there are three completely different failures, and using the wrong fix wastes your time. The test is simple: is the entry missing, is the list blank, or is there an error? This article gives the diagnosis and steps for each.

Overview: first identify which kind of DSH Plugin Hub "won't open" you have

"Won't open" splits into three layers in DSH Plugin Hub: the entry layer (does Settings show a plugin market at all), the data layer (did the list load), and the link layer (does the error point to network, registry or credentials). The official troubleshooting docs group download problems into timeout/disconnect, 404, and 401/403 — and the same split applies here (source).

The symptom decides the direction — match your case before touching anything. Find your row in the table:

Missing entry: DSH Plugin Hub isn't installed or isn't active

If Settings has no plugin market entry, it is almost always DSH Plugin Hub not installed or not active (source).

1. Reinstall the Hub:

dsh plugin --profile web add dsh-plugin

Expect: installation succeeds with no terminal error. If it errors, determine whether it's the network or the registry first (see the 404 section below); 2. Restart dsh web. Expect: the service reloads its plugins; 3. Refresh the page and open Settings → Plugin Market. Expect: a list of plugin cards, which means the entry is live.

dsh plugin market empty list: the catalog never loaded

A dsh plugin market that opens but shows zero plugins means the UI is there and the data isn't — the problem is the network path, not the plugin itself (source).

1. Confirm the machine has outbound access. Expect: the browser can open sites you normally visit. Corporate or campus networks that require a proxy usually expose the problem at this step;
2. Configure a terminal-level proxy. Expect: on macOS / Linux set http_proxy and https_proxy in the shell; on Windows PowerShell use $env:HTTP_PROXY; this applies to npx, git and pnpm alike;
3. Restart dsh web so it re-fetches the catalog. Expect: plugin cards appear in the list.

dsh error classes: timeout, 404 and 401/403

The dsh error text itself points the direction: timeout/disconnect means network, 404 means registry and package name, 401/403 means credentials and origin validation (source).

1. ETIMEDOUT, ECONNRESET, ECONNREFUSED and friends. Expect: a network or registry issue — handle it with the proxy and mirror steps above;
2. E404, 404 Not Found. Expect: usually a wrong package name or version. If installing a plugin reports ERR_PNPM_FETCH_404, that is a lagging registry mirror — verify against the official registry:

dsh plugin --profile web add <package> --registry=https://registry.npmjs.org

The environment-variable form works too: npm_config_registry=https://registry.npmjs.org dsh plugin add <package>; 3. 401. Expect: credential-related; check provider keys or the relevant authorization settings; 4. 403. Expect: a Host / Origin validation failure — the origin isn't trusted (DNS rebinding and cross-site request defenses). Not an account restriction, and not a plugin-market-specific error.

On networks where timeouts are common, switching mirrors helps:

npm config set registry https://registry.npmmirror.com

Expect: packages now fetch through the mirror with more stable speed. Remember that mirrors lag: when a 404 shows up, verify against the official registry as in step 2 (source).

Windows special case: the dsh sandbox breaks Schannel

If HTTPS requests fail wholesale on Windows and the log reports SEC_E_NO_CREDENTIALS, the thing to investigate is the sandbox and the system TLS stack, not the network (source). That error means the Windows sandbox or an isolated environment can't obtain TLS credentials and has broken Schannel (the system HTTPS stack), so no HTTPS connection can be established.

1. Switch the run preset back to the full-access preset first. Expect: HTTPS requests return to normal after restarting dsh;
2. Or switch to a node / python runtime. Expect: the sandbox credential restriction is bypassed;
3. If the system reports a missing certificate, install / import the matching TLS credential as prompted. Expect: HTTPS succeeds once the credential is in place;
4. Re-check: reopen the plugin market. Expect: the list loads and installs work normally.

Configure registry and proxy in DSH Plugin Hub settings, and export the logs

Rather than tweaking environment variables in terminals, configure the mirror and proxy once on the DSH Plugin Hub settings page; when you still can't pin it down, export the log trail it records itself (source). The left side groups update settings, security trust, system diagnostics, system logs and restore defaults:

Configure registry and proxy

"Update settings" holds the check-on-startup toggle, the npm registry dropdown and the proxy address field; after configuring the proxy and mirror, restart dsh web and reopen the market — far less work than editing environment variables across several terminal windows:

1. Open Settings → Plugin Market → Settings. Expect: the three options in the "Update settings" group;
2. Pick a working npm registry, fill in the proxy address and save. Expect: the configuration is written and takes effect immediately;
3. Restart dsh web and refresh the market page. Expect: the list loads normally and installs no longer time out.

Still stuck: export the system logs

When you still can't pin it down, the Hub's own log trail is the fastest answer. The system logs page records installs, uninstalls, settings changes and diagnostics, viewable by category and level, and exportable:

1. Go to Settings → Plugin Market → System Logs. Expect: log entries arranged by time, level and category;
2. Reproduce the failure once. Expect: a matching failure record appears at that timestamp;
3. Use "Export logs" or "Copy all". Expect: you get the complete error context, ready to compare or to ask about.

Sources: dshplugin/dsh-plugin-hub, DeepSeek Harness Docs - Quickstart, dsh CLI README, npm config docs