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 intopackage.json’sdsh.profile.bundlesand reportsneedsRestart - 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.bundlein manifest):installexecutespnpm addand inserts a real-time Loader entry in the hosted block; it installs and enables immediately. - Bundle plugin (declares
dsh.bundle):installexecutespnpm addand syncs the name intopackage.json’sdsh.profile.bundles(same rule asdsh plugin --profile … add). The bundle patch layer is read at startup, so this step reportsneedsRestart; 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:
- Choose one of the two installation methods, do not mix them.
- 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.
- Bundle plugins will report
needsRestartafter 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).