Preface¶

The plugin mechanism of DSH (DeepSeek Harness) isn’t particularly complex; the difficulty lies in what happens after installing many of them. Once you have dozens of plugins, the problem is no longer “which plugin is called what,” but rather “what exactly do I have running right now.” The official plugin page provides a flat list of installed plugins, including both enabled and disabled ones, making it hard to distinguish by memory: it is common to leave plugins enabled during installation and forget to disable them when using them.

The dsh-plugin-packs introduced below solves this perspective problem. It is maintained by mmmmlp-cloud, under the MIT license, current version 0.1.0, and categorized as “Workflow” in the community directory. It rearranges installed data into a Minecraft resource pack-style left-right column view (left column is in use, right column is installed but not enabled), with an overlay of manually editable tags. The repository is relatively new, with 0 public stars, making it suitable for users willing to try first and provide feedback.

What is it¶

One-sentence positioning: A DSH plugin pack manager that answers “is this pack currently on or off” using a two-column view, and “what category does it belong to” using tags.

It is not an uninstall tool, nor a plugin grouping tool. The difference lies in the perspective: grouping plugins answer “which category does it belong to,” organized in user-defined hierarchies; this plugin answers “is it currently running,” where the left column is the bundle selection for the current profile, and the right column is unused packs. Both can be installed simultaneously without writing to the same data set.

Core Features¶

After installation, the plugin adds a “Plugin Packs” tab at the top of the “Plugins” page in the left sidebar, with the following capabilities:

• Two-Column View: Left column “Enabled · Together”, Right column “Disabled”. Cards are square, two per row per column.
• Move Packs: Click the → / ← arrows in the top-right corner of the card, or drag directly to the opposite column, to enable/disable.
• Batch Operations: After selecting multiple cards, a “Batch Enable / Batch Disable” floating menu appears at the top.
• Tags: Cards can have custom tags; clicking a tag in the top tag bar filters, clicking it again cancels; “Unmarked” retrieves packs not yet categorized.
• Search: Matches Chinese name, package name, description, version, and tags.
• Scope Filtering: By default, only user-installed packs are shown; options include Official Optional Packs, All; checking “Show System Core” reveals read-only areas.
• Expand Details: Expand to view full description, source, list of plugins inside the pack, and runtime status, as well as edit the Chinese name and check tags.
• Toggle Feedback: After each toggle, a prompt distinguishes four outcomes: Applied / Requires DSH Restart / Overridden by Higher Priority / Failed: <code>, the first two support undo.
• Session Memory: After visiting the “Plugin Packs” page once, switching away and returning within the current session keeps you on that page.

Installation and Enablement¶

Installation is done via the official DSH CLI, specifying --profile web (browser half needs to be attached to the web profile):

# Official CLI: use pnpm to install and select the bundle
dsh plugin --profile web add github:mmmmlp-cloud/dsh-plugin-packs

After installation, restart dsh web once (the host half needs routing), then press Ctrl+F5 to hard refresh the page. The entry is in the left sidebar “Plugins” → top “Plugin Packs”.

Note that DSH has two entries both called “Plugins”: the left sidebar is the plugin overview page, and “Settings → Plugins” is the other face. This plugin is attached to the former; when troubleshooting, first confirm this.

Where Data Exists¶

Tags and Chinese names are not written to browser localStorage but are written to a regular JSON file that follows DSH_HOME:

<$DSH_HOME>/plugin-packs/packs.json
# Default path is C:\Users\<Username>\.dsh\plugin-packs\packs.json

File format:

{
  "version": 1,
  "tags": [{ "id": "novel", "label": "Novel · Reading", "color": "#7B68EE" }],
  "packs": {
    "dsh-novel-writer": { "name": "Novel Writing Assistant", "tags": ["novel"] }
  }
}

Key Points:

1. The key for packs is the package name, not the entry id. Reinstalling, upgrading, or changing directory IDs won’t lose tags.
2. An empty table is generated if the file doesn’t exist, accompanied by 7 general category tags (Novel · Reading / Online Search / UI Enhancement / Security · Penetration / Model Channel / Memory · Knowledge / Tools · Others). No packs or ownership are pre-filled; the user decides which tags apply to which pack.
3. Can be manually edited directly; refresh takes effect; if the format is wrong, data won’t be silently lost (a broken file is renamed for backup packs.json.broken-<timestamp> before rebuilding).
4. Writes are atomic (temp file + rename) and serialized, so clicking tags consecutively won’t cause updates to swallow each other.
5. It only involves plugin packs and does not touch sessions, prompts, or credentials; changing machines doesn’t sync with the account, requiring manual copying.

Which Layer Does It Modify¶

“Enable/Disable” calls the kernel’s pluginManager.setBundleEnabled, adding the pack to or removing it from the profile’s bundle selection layer. It modifies the real plugin state, not the page display: dependencies remain in node_modules and can be moved back at any time; it is not uninstallation. Packs that are taken over by upper-layer configuration (read-only) are clearly marked and cannot pretend to be switchable.

The switches for individual loader lines inside a pack are outside the scope of this plugin; the list of lines in the pack on this page is read-only display; dedicated line-level tools are needed for line-level management.

There is protection on the scope: checking “Show System Core” reveals dsh-base / dsh-web-app as well as packs for other runtime modes like acp, headless, sdk-app, and sdk-minimal. These are all non-switchable to prevent accidentally breaking the desktop configuration. Packs that are not installed (availability === "missing") are not displayed.

Architecture and Interfaces¶

Packs consist of a host half and a browser half, with zero runtime dependencies and no build steps. Browser-side data uses the host half’s same-origin routes and can be verified individually with curl:

This is done because the browser calling ctx.remote.pluginManager directly requires handling client-side remote assembly order and is prone to silent failures during startup races; going through the host route is unaffected. Write operations carry a custom request header and the route does not answer pre-flights, preventing other local pages from hijacking to change plugin state.

When troubleshooting, check the self-check interface first:

curl 127.0.0.1:<port>/plugin-packs/api/health

The existence of the build field indicates the route is normal; if the page reports HTTP 404 / Response is not JSON, it is usually because the host code was changed but the bundle row was not reapplied; re-enabling/disabling once is enough, no need to restart DSH.

Applicable Scenarios and Notes¶

Suitable for plugin counts in the dozens, users who are used to managing packs by purpose, and those willing to put categories into a manually editable file. Tags follow DSH_HOME, so changing browsers or clearing site data won’t lose them.

Watch out for a few points:

1. Plugins run with the permissions of the current dsh process and can read/write all plugin packs accessible by that profile. It is recommended to read the source code and license (MIT) before installing.
2. It only manages the pack level; individual line-level switches inside a pack require finding another line-level tool.
3. The official “Installed” tab itself cannot be replaced; this plugin provides an alternative perspective as a parallel tab; both coexist.
4. For certain packs (especially host-side plugins), toggling requires restarting dsh web to take full effect, and the page will explicitly prompt this.

Conclusion¶

What dsh-plugin-packs does is small: it rearranges the existing plugin list into daily language—two columns, tags, search, and batch operations. It does not introduce a new installation method, nor does it modify kernel semantics; it just turns “what I am running right now” from a memory problem into a visible fact. If this is your pain point, you can start trying from the community directory page:

• Directory page: https://www.skillhub.cn/plugins/mmmmlp-cloud/dsh-plugin-packs
• GitHub: https://github.com/mmmmlp-cloud/dsh-plugin-packs