Introduction

The extension approach of DeepSeek Harness emphasizes “everything is a plugin”. Plugins can be combined with each other and also distribute stability risks across loaders, dependencies, runtime, installation scripts, duplicate installations, and patch consistency. dsh-plugin-clinic fills in this layer of read-only health checks: it checks the installed profile plugin collection under Harness home, does not write to external state, does not perform fixes, and outputs results via model tools, a web dashboard, and JSON reports.

What is it

dsh-plugin-clinic is a DeepSeek Harness plugin maintained by ayahunter, licensed under MIT. It focuses on health checks for installed plugin sets, providing the plugin_health model tool, the Clinic / Health Check tab in Settings → Plugins, and JSON reports for CI and scripts.

Core Features

Below are the capabilities it currently provides:

  • Model tool plugin_health: Diagnoses the current environment in a session and can convert check results into specific repair suggestions.
  • Web dashboard: Provides the Clinic / Health Check tab in Settings → Plugins, displaying a plugin health overview by profile.
  • JSON reports: Provides a stable schemaVersion: 1 contract for CI and scripts.
  • 8 read-only checks: load-health, bundle-manifest, peer-deps, runtime-compat, install-scripts, duplicate, patch-health, provenance.
  • One-row install: Mounts the Host engine and browser dashboard with a single npm bundle patch.

Installation and Setup

First, confirm the Node version. The engines.node in package.json is:

^22.19.0 || >=24.0.0

Installation command:

dsh plugin --profile web add dsh-plugin-clinic

After installation, restart the corresponding profile. The Clinic / Health Check tab will appear in Settings → Plugins, and the plugin_health tool will appear in the session.

Upgrade command:

dsh plugin --profile web update dsh-plugin-clinic

Upgrades are not applied automatically; the profile needs to be restarted after upgrading. If installing from source, the prepare script will build the sources, and pnpm will require permission for a single build.

Configuration

The cordis.patch.yml configuration items in the README example are as follows:

- id: clinic
  name: 'dsh-plugin-clinic'
  config:
    profiles: []
    enableTool: true
    enableWebRoute: true
    webRoutePrefix: '/clinic'
    includeHomePatches: true

These configuration items include profiles, enableTool, enableWebRoute, webRoutePrefix, and includeHomePatches. Among them, profiles is used to limit the profile directory names to be diagnosed; an empty value means all. enableTool corresponds to the plugin_health tool. enableWebRoute corresponds to registering the /clinic HTTP route when the webServer exists. webRoutePrefix is set to /clinic in the example.

Typical Usage

  1. Send in any profile session where the plugin is installed:
Check my plugins
  1. Pass details: true when calling the tool directly to get evidence for each finding:
{ "details": true }
  1. Open in the Web GUI:
Settings → Plugins → Health Check

To view the health overview of each profile.

  1. Get reports via HTTP endpoints:
GET /clinic/health
GET /clinic/health/summary

GET /clinic/health returns the full ClinicReport; GET /clinic/health/summary returns the dashboard summary projection.

Boundaries and Considerations

  • Read-only diagnosis: v1 only does diagnosis, not repair; repair is an agent/user action.
  • Offline check: v1 is completely offline, with no npm online checks; deprecated flags and update availability belong to v2.
  • Current profile: The current profile cannot be detected; v1 diagnoses all profiles by default. The --profile extracted from argv is just best-effort UI highlighting, not authoritative.
  • Browser-first dashboard: The Clinic tab has been verified against the official Web GUI; Electron desktop shells have not yet been verified.
  • Loader-only plugins: Loader-only plugins without a package.json do not apply checks like peer-deps, runtime-compat, install-scripts; they only apply to load-health and provenance.
  • No source-level security scan: This capability belongs to dsh-plugin-doctor; optional integration is deferred to v2.
  • Reports are point-in-time snapshots: No cache, history, or subscription.
  • HTTP routes require a loopback Host header, used for DNS-rebinding defense, but not for authentication.

Use Cases

Suitable for use in the following scenarios:

  • Quickly checking plugin loading, dependencies, and patch status of the current profile in an agent session.
  • Viewing plugin health overviews of multiple profiles in the Web GUI.
  • Integrating JSON reports into scripts or CI pipelines.

Usage Notes:

  • Plugins run with the permissions of the current dsh process. You should check the source code, license, and dependencies before installing; the license is MIT.
  • It does not replace source-level security scanning and does not perform repairs.
  • If you only need offline, read-only first-layer diagnosis, it can serve as an entry point for plugin set health checks.

Links

  • GitHub: https://github.com/ayahunter/dsh-plugin-clinic
  • Directory Page: The verified information does not provide a specific URL; dsh-plugin-clinic can be searched in the DSH plugin directory.