Plugin market install failed: read DSH Plugin Hub alerts

You click Install three times, the card spins, the dialog closes, and the error is nowhere to be found — the classic plugin market install failure is not a missing error but an error that appeared exactly once. DSH Plugin Hub actually leaves three evidence sources: the confirmation dialog, the notification center and system logs (2.2.5 index). Most people only watch the dialog and lose the trail when it closes. This article follows a triage table: pick the right source first, then use logs to pin the failure to a stage. The entry is on DSH Plugin Hub.

Three evidence sources in DeepSeek Harness: dialog, notifications, logs

The three sources answer three different questions: the dialog answers "did this action fail", the notification center answers "what just happened", and system logs answer "why did it happen". Using the wrong source leads to refreshing the wrong screen.

1. Open the notification center before installing so it has a chance to record the whole process.
2. When the dialog appears, screenshot or copy the plugin name and source before clicking Confirm.
3. After a failure, copy the full log from notifications first, then find the same timestamp in system logs.
4. Only if both sources are empty should you reproduce once — and only once.

The sources do not replace each other. The dialog confirms on the spot, notifications let you look back, and logs locate the cause. Reverse that order and you are searching a haystack.

DSH Plugin Hub notifications: progress, failure and pending restart

Read three record types first: failed tasks, tasks stuck in progress, and tasks with a pending-restart reminder. Successful records only need a glance — their main value is a timeline.

1. Open the notification center and read the three most recent records in reverse chronological order.
2. Open the failed task and copy the full log; do not record only the last red line.
3. For a task stuck in progress, decide whether the network is slow or the process is wedged, and do not resubmit repeatedly.
4. A pending-restart reminder means the install was written but never mounted — restart the host instead of reinstalling.
5. Copy or screenshot the evidence you need before clearing; a one-click clear cannot be undone.

Pending restart is the most misread state: users assume the install failed when it simply has not been restarted. In notifications the two look different — a completed install has a completion record, a real failure does not. Telling them apart removes half of all unnecessary reinstalls.

Before clearing, keep at least three things

1. The full log of the failed task, copied rather than screenshotted at the last line.
2. The plugin name and source repository from this attempt, for checking the market or repository later.
3. The operation timestamp, to align with entries in system logs.

With those three, a cleared notification history still leaves you a reproducible trail.

Filtering dsh plugin market system logs by category and level

Filter in the order category, then level, then time until only a few lines remain. Reading from the top rarely finds the line that matches this failure among hundreds of records (2.2.5 index).

1. Open Settings → Plugin Market → System Logs and click Refresh first.
2. Filter the category to the operation type involved: install, uninstall, update or settings change.
3. Filter the level to error or warning; if no error appears, check info level to confirm the request was sent at all.
4. Align entries with the reproduction time and read only records added after this operation.
5. Use Copy Full Text or Export Logs to take evidence away instead of transcribing it by hand.

The log page can also relocate the log directory and open the file. If you expect long-term troubleshooting, point logs at your own working directory so future comparisons are easier. Beyond category and level, time is the most reliable anchor: note the minute you clicked Install, then return to that minute.

From logs to four DSH plugin stages: download, unpack, dependency, load

The same "install failed" message demands completely different fixes depending on the stage: download points at network, unpack at files, dependency at the package manager and load at the entry. Identify the stage before acting.

1. Download: the log shows timeouts, connection resets or 404s. Check proxy and mirror; on a 404, verify with the official registry instead of renaming the package.
2. Unpack: the log shows a corrupt archive, write failure or permission denial. Check disk space, target directory permissions and antivirus interference.
3. Dependency: the log shows pnpm resolution failure, a rejected build script or a version conflict. Check dependency declarations, build-script approval and package manager version.
4. Load: the log shows a missing entry file, module resolution failure or activation error. Check the package.json entry against the actual artifact, which is common with source installs.

The four stages produce four evidence types: network, file, dependency and code errors. Match the log keyword to a stage, then return to the triage table at the top for the response. A fuller failure map is in the plugin install failure map.

Verifying the fix: is the DeepSeek Harness plugin active?

Fixed is not the same as active; verify three places — the installed list, the entry after restart, and the absence of new activation errors in logs. A green card only proves the write completed.

1. Return to Installed and confirm the entry exists, the version is right and the source label is correct.
2. Restart DeepSeek Harness and reopen the menu, command or panel the plugin provides.
3. Invoke the plugin capability once, confirming that more than a UI element exists.
4. Check system logs again and confirm there is no new error for the same plugin.
5. If it still fails, keep this round of logs and timestamps, then re-run the four-stage mapping.

Do not change several variables at once during verification: restart, check the entry, then read logs. One change at a time is the only way to know which step fixed it. For where to configure notifications and logs, see how to configure DSH Plugin Hub settings; for more on install-stage logging, see how to read plugin market install logs.