Preface

The philosophy of DSH (DeepSeek Harness) is “everything is a plugin”. However, the current workflow for installing plugins involves putting packages into the profile, manually editing cordis.patch.yml, restarting the server, and repeating this process for the next plugin. Two or three plugins are manageable, but once there are many, you are always editing the same YAML file and always following the same restart process.

Below is an introduction to dsh-plugin-manager. It consolidates installation, enabling/disabling, and uninstallation into a Web GUI, an independent CLI, and a chat command, eliminating the need to manually edit configuration files throughout.

What is it

dsh-plugin-manager is a dsh plugin used to manage other dsh plugins. It is maintained by OSSKn4w7, has the npm package name @osskn4w7/dsh-plugin-manager, current version 0.1.2, is under the MIT license, and the source code is in the GitHub repository OSSKn4w7/dsh-plugin-manager.

It writes the cordis.patch.yml of the profile for you: changes are written into a delimited auto-hosted block, while your hand-written patches are preserved byte-by-byte; the Host-side User Patch Monitor (HMR) in the running server applies these changes immediately, so most operations do not require a restart.

The entire package consists of four parts:

Component Function
lib/index.js Host side: JSON API under /plugin-manager/api + /plugin chat command
lib/client.js Browser side: “Plugin Management” tab in Settings → Plugins
lib/core.mjs Shared logic: hosted block editing of cordis.patch.yml, pnpm runner, bundle reconciliation
bin/dsh-plugin-manager.mjs Independent CLI (available when server is stopped)

Core Features

  • Provides “Plugin Management” Web GUI tab in Settings → Plugins
  • Installs plugins by npm package name, with optional JSON configuration
  • One-click enable/disable any loader entry, takes effect in real-time, no restart needed
  • Uninstalls plugins
  • View combined full Loader tree, profile dependencies and bundles, and which entries the manager itself has installed
  • Automatically maintains the delimited auto-hosted block in cordis.patch.yml, preserving hand-written patches byte-by-byte
  • Independent CLI dsh-plugin-manager, usable even when server is stopped
  • Chat command /plugin (list / enable / disable / install / remove)
  • For plugins declaring dsh.bundle, automatically syncs the name into package.json’s dsh.profile.bundles and reports needsRestart
  • Provides JSON HTTP API under /plugin-manager/api

Installation

Prerequisites: pnpm in PATH; a web profile (or any profile with a web bundle); a server bound to loopback (default is).

There are two installation methods; you can only choose one, mixing them will result in the same entry being inserted twice.

Method A: Standard dsh bundle installation

dsh plugin --profile web add @osskn4w7/dsh-plugin-manager

Execute the command above first, then restart the dsh web—bundle patch layers are read during startup.

Method B: Real-time installation without restart

dsh-plugin-manager bootstrap --profile web

bootstrap wraps this via pnpm into $DSH_HOME/profiles/web and writes its Loader entries into cordis.patch.yml. The profile patch file is monitored in real-time, so the Host-side immediately activates; after that, refresh the browser once to load the client bundle (Settings → Plugins → Plugin Management).

If you want to use the CLI separately from the profile:

npm i -g @osskn4w7/dsh-plugin-manager
dsh-plugin-manager list --profile web

Typical Usage

The three entry points accomplish the same thing.

Web GUI: In the “Plugin Management” tab of Settings → Plugins, install by npm package name (optional JSON configuration can be filled in), click buttons to enable/disable, uninstall, and view the complete Loader tree.

CLI:

dsh-plugin-manager list [--json] [--profile web]
dsh-plugin-manager enable <entry-id>    # disable for disable
dsh-plugin-manager install <pkg> [--config '{"a":1}']
dsh-plugin-manager remove <pkg>
dsh-plugin-manager bootstrap

Chat command, type directly in the web chat:

/plugin list
/plugin enable <id>
/plugin disable <id>
/plugin install <pkg>
/plugin remove <pkg>

What happens behind enable/disable: Add/remove a disabled patch targeting the ID in the hosted block; the monitor restructures the tree, taking effect in real-time.

Ordinary plugins and bundle plugins behave differently and need to be understood:

  • Ordinary plugin (no dsh.bundle in manifest): install executes pnpm add and inserts a real-time Loader entry in the hosted block; it installs and enables immediately.
  • Bundle plugin (declares dsh.bundle): install executes pnpm add and syncs the name into package.json’s dsh.profile.bundles (same rule as dsh plugin --profile … add). The bundle patch layer is read at startup, so this step reports needsRestart; after restart, the entry appears and can be switched normally.

Boundaries of the Hosted Block

The hosted block in cordis.patch.yml is delimited by two lines of comments:

# >>> dsh-plugin-manager … >>>
# <<< dsh-plugin-manager <<<

Edits inside the block will be overwritten; everything outside the block belongs to the user—hand-written patches are preserved byte-by-byte, which is the premise for it to dare to edit the file for you.

Two other details are worth noting: lines that are disabled but whose ID no longer exists in the combined tree will log a benign loader warning; when uninstalling a package, the manager will remove the corresponding patch.

Suitable Scenarios and Precautions

Suitable for: Developers who frequently install and experiment with dsh plugins; those who need to switch plugin start/stop while the server is running; people who don’t want to manually maintain cordis.patch.yml anymore.

Precautions before use:

  1. Choose one of the two installation methods, do not mix them.
  2. The HTTP API only listens on loopback (consistent with the server’s default binding) and has no authentication, so do not expose the web server to untrusted networks.
  3. Bundle plugins will report needsRestart after installation; the entry only appears and can be switched after one restart.

Finally, a reminder of convention: Plugins run with the permissions of the current dsh process, so you should check the source code and license before installing any plugin. This plugin is MIT.

Conclusion

Following the steps above, plugin management has changed from “edit file, restart, edit again” to “click once, take effect in real-time”. The hosted block mechanism separates the automated writing from your hand-written patches, causing no interference. Repository address: https://github.com/OSSKn4w7/dsh-plugin-manager; listing page can be found in the community plugin directory: https://www.skillhub.cn/plugins/OSSKn4w7/dsh-plugin-manager (this directory is an independent community site and has no official affiliation with DeepSeek or HF).