DSH Plugin market install fails: logs and issue evidence

A DSH Plugin market install that ends in a red toast tells you nothing about where it broke. Reading the log as a sequence of stages — download, unpack, dependency, load — turns that single failure into a location, and a location into a fix.

A failed DSH plugin install is a story with four stages

The log records stages in order, so the first line that fails is the only line that matters yet.

A market install looks like one action because the interface presents one button. Underneath, the client fetches a package, writes it to disk, resolves dependencies and finally asks the runtime to load it. Each step can fail for unrelated reasons, and each writes a distinguishable error. The first failure is the boundary between worked and not.

The common mistake is to read the last line, which is often a generic wrapper such as "installation failed". The line above it usually names a file, a package or an exit code. Scroll up until the messages stop being about progress and start being about a problem.

Once the stage is known, the search space collapses. A download failure is about reachability; an unpack failure is about the archive; a dependency failure is about resolution; a load failure is about compatibility. Each sends you to a different set of logs, so identifying the stage first saves an hour of guessing.

The download stage in a DSH plugin install log

A download failure happens before anything is written, so the evidence lives in the client and the network.

If the log stops while fetching, look for the URL it tried and the response it received. Timeouts, certificate errors and 404s mean different things, and the difference matters more than the wording of the toast. A 404 usually means the version is gone; a timeout usually means a proxy or registry problem.

Reproduce the fetch outside the interface so the output is not abbreviated. The exact package name and version from the entry are what you need, not the display name. A single command with those two values shows the resolved URL and the underlying error code.

dsh plugin add @scope/example-plugin@1.4.2 --verbose

Keep the full output rather than the final line. Warnings about redirects or deprecated registry endpoints often explain a failure that appears later. If the same command succeeds, the package is reachable and the client path is suspect.

Unpack and dependency failures in DSH plugin installs

An unpack or dependency failure means the bytes arrived but the environment could not turn them into a usable package.

Unpack errors mention archive corruption, checksum mismatch or a path that cannot be written. They point at the transfer or the install directory, not at the plugin's code. Dependency errors name version ranges, peer requirements and the package that could not be satisfied. Both are common with DSH plugins that ship native modules or install scripts.

The package manager's own log is the place to confirm which one happened. Find its cache directory first, then read the log for the failing command instead of assuming a fixed path. The file records the resolution tree and the error class.

npm config get cache
#logs for the last install live under _logs
pnpm store path

Classify the error before changing anything. A network class needs connectivity, a resolution class needs a version decision, a build class needs a toolchain, and a permission class needs a writable directory. Changing two of those at once produces a success you cannot explain and a failure you cannot repeat.

When the DeepSeek Harness plugin installs but will not load

A successful install only means the files exist; loading a DeepSeek Harness plugin adds checks with their own failures.

Loading adds the runtime version, the plugin's declared entry point, and the API surface it expects. Errors here often mention a missing export, an unsupported engine range or an initialization exception. None are fixed by reinstalling.

This is where the runtime log matters, and where install logs stop being useful. Look for the plugin name, the version that was loaded and the first exception after activation. If the status stays pending or failed, the message next to it is the actual diagnosis. Check what the runtime thinks is installed before reading further:

dsh plugin list

Compare that version with the one in the shortlist. A mismatch explains many "installed but broken" reports, because the old copy is still the one being loaded. If the versions match, the problem is the load path itself, and the exception text is the next thing to read.

Turning a DSH plugin install log into evidence

Reading the log is diagnosis; turning it into an issue is a separate skill that decides how fast it gets fixed.

A useful report lets someone else reach the same stage with the same inputs. That means the package and exact version, the Harness and Node versions, the operating system and the failing command. Logs without that context are anecdotes.

Sanitize before posting: tokens, internal hostnames and usernames do not need to travel with the stack trace. Keep the error text and the surrounding few lines, because the line before the exception usually carries the cause. A trimmed log that still shows the stage is worth more than a file dump nobody reads.

The short sequence below is enough for most reports and keeps the evidence comparable across environments. It also stops a thread from turning into guesswork. A reader who can follow it should reach the failure without trial and error.

1. Record the failing stage from the first error line.
2. Add package, exact version and how it was installed.
3. Add Harness, Node, package manager and OS versions.
4. Paste the command and its full output for that stage.
5. List what you already ruled out, one variable per line.
6. Sanitize secrets and internal addresses before posting.