Preface¶

The design slogan of DeepSeek Harness (dsh) is “Everything is a plugin”: models, tools, sessions, sandboxes, and interfaces can all be replaced with plugins, and Cordis is responsible for mounting and dependency management. The official assembly follows configuration: the profile’s cordis.patch.yml, bundle list, and repository plugins. After modifying a local plugin package, you usually need to restart the web process for the bundle to take over again.

This path is heavily production-oriented for plugin developers. Debugging a complete package with host tools and client UI has high restart costs; if hot reload fails and leaves residual routes, ghost entries, or half-baked caches, troubleshooting can be difficult. The community plugin dsh-super-injector addresses this runtime management scenario: first install the injector via the official path, then inject local plugin packages into the running web instance without modifying patch, package.json, or the bundles list, and without killing the process.

This article is collated after cross-checking with the community directory page, GitHub README / INSTALL.md / docs/SPEC.md, package.json, and the v0.3.3 Release. This directory is an independent site and has no official affiliation with DeepSeek / Fangxin. Do not treat it as an official app store.

What is this¶

dsh-super-injector is a runtime module injector for DeepSeek Harness, maintained by GitHub user yjh051108, and categorized under “Tools and Capabilities” in the community directory. The repository address is https://github.com/yjh051108/dsh-super-injector. As of 2026-08-17, the GitHub API shows 87 stars for this repository; the directory page snapshot at that time had 34 stars, so please refer to the repository page for the latest count.

The package name in package.json is @dsh-external/dsh-super-injector, current version 0.3.3, primarily written in TypeScript, with dsh.client.platform declared as web. The license specified in package.json is BSD-3-Clause; there is no standalone LICENSE file in the repository root, so you should independently verify that the source code matches the declared license before installation.

The problem it solves can be summed up in one sentence: inject, hot reload, side-load test, uninstall, and roll back on failure, a “pre-built standard plugin package” (package.json + lib/) into a running web profile. The repository README compares it to the BepInEx-style entry point in the gaming ecosystem — the official assembly mechanism only installs the bootloader once, and all other modules use runtime injection afterward.

Starting from v0.3.0 (2026-08-14), the author refactored the self-reload feature according to the repository’s docs/SPEC.md. This specification is based on the source code semantics of loader / include / cordis in DSH 0.1.0-rc.6: the tool is only responsible for scheduling, reboot uses the official REPLACE structure (entry._dispose, loader’s _disposing exemption), and automatically rolls back on failure. The CHANGELOG records that since v0.2.6, it has “run unchanged” on 0.1.0-rc.6; this is the maintainer’s compatibility statement, not an official DeepSeek certification.

Core Features¶

Runtime Injection, Not a Second Installation Library¶

The injector itself must go through the official assembly process first. After installation, call dev_inject_plugin on the local plugin directory: junction the plugin package to ~/.dsh/profiles/web/node_modules, then run ctx.loader.create({ name, config }). The README emphasizes that the injection manifest only restores the cache at runtime, stored in ~/.dsh/super-injector/registry.json, and will automatically reset after the web restarts; for production use, use dev_install_package to write to the profile bundles, which will be taken over by the official list after restart.

Both the host tools and client UI should be available after injection. The implementation clears loader ghost entry isolation (normalizeEntry) and supplements scanning / linking / uninstalling the client module table. Each injection, reload, and installation will return a dual verification of host ✓ / client ✓.

Hot Reload, Self-Reload, and Automatic Watch¶

dev_reload_package performs a full package reload: clear cache → re-import → rebuild fiber. If it fails, it rolls back and retains the old version. The injector itself also supports self-reload. Starting from v0.3.0, this path aligns with the REPLACE branch of the official entry.update instead of manually writing “suicide and rebuild”.

The injected plugin directory will be automatically watched: after modifying the code and completing the build, the README states that it will automatically reload in approximately 1.5 seconds. An import pre-check will be performed before watching, and a damaged lib will reject the reload to avoid crashing the process with half-baked code. The SPEC codifies the principle: use touch patch (include.refresh, only effective for entries without fibers) for recovery, use self-reload for updates, never kill the process.

Development Staging Area¶

Tools under test can first be mounted to the “staging side” without entering the tools schema, avoiding disrupting the prefix cache due to fluctuations in the development tool set. The corresponding tools are dev_stage_add / dev_stage_call / dev_stage_list / dev_stage_promote / dev_stage_demote. Promotion only refreshes the cache once; staging data will be persisted, and promoted tools can be restored after self-reload or restart.

Uninstallation, Route Self-Healing, and Status Query¶

dev_uninject_plugin runs fiber disposal, cleans up tools, listeners, routes, and client tables, then clears the injection manifest and deletes the junction, no restart required. When uninstalling bundle plugins, it will also write disabled to prevent include.refresh from re-adding the plugin.

If orphaned routes are left over from hot reload, use dev_clear_routes to clear the webserver’s internal routing table by path prefix. dev_injected_list lists the injection manifest; dev_plugin_status provides assembled plugins, fiber status, and operation success rate.

Plugin Development Workflow¶

The README also provides three tools for scaffolding / building / releasing: dev_scaffold_plugin (toolkit / daemon-loop / ui-panel / hybrid), dev_build_plugin, and dev_release_plugin. These are intended for “writing complete plugin packages from scratch”, unlike the creative mode of dsh-evolve which generates single-file .mjs in conversations. The maintainer describes the two as complementary: the source code generated by evolve can be upgraded into a complete package, then hot-mounted via the injector.

Installation and Activation¶

The installation command given on the community directory page is:

dsh plugin add github:yjh051108/dsh-super-injector

This plugin declares the web platform. Both the repository README and INSTALL.md specify explicitly specifying the profile:

dsh plugin --profile web add github:yjh051108/dsh-super-injector

The directory page reminds users: for reproducible installations, you should pin the commit hash. The latest Release as of now is v0.3.3 (2026-08-15), corresponding to commit 51dcda74a784cf113e850899b43a1a22e3799e91:

dsh plugin add github:yjh051108/dsh-super-injector#51dcda74a784cf113e850899b43a1a22e3799e91

INSTALL.md recommends Option A: download dsh-external-dsh-super-injector-<version>.tgz from Releases (the asset name for v0.3.3 is dsh-external-dsh-super-injector-0.3.3.tgz), extract it:

mkdir -p ~/dsh-super-injector && tar -xzf dsh-external-dsh-super-injector-0.3.3.tgz -C ~/dsh-super-injector --strip-components=1
dsh plugin --profile web add ~/dsh-super-injector

Official bundle assembly completes at startup, and you need to restart the web process. After restarting, send dev_plugin_status to the agent, and when you see dsh-super-injector with an active status, run dev_self_test. INSTALL.md states that the self-test has 8 items, and all are expected to PASS.

The v0.3.3 Release notes bundle runtime dependencies into lib/index.js to avoid Cannot find package '@deepseek-ai/dsh-tools' during official assembly. Installing from git source still requires a local build environment (bash, node, npm, and a DSH checkout or DSH_CHECKOUT). On Windows, INSTALL.md requires using Git Bash or WSL to run bash syntax; v0.3.3 will also reject System32\bash.exe that takes precedence in the PATH, prioritizing Git Bash.

The plugin runs with the permissions of the current dsh process, and may execute code during installation. Please inspect the source code repository and license before installing.

Typical Usage Examples¶

The following commands and dialogue instructions are from the repository README / INSTALL.md, replace the paths in the parameters with your local absolute paths.

1. Confirm that the injector is mounted

dev_plugin_status
dev_self_test

2. Inject a pre-built local plugin package
After obtaining the directory containing package.json and lib/, send this to the AI:

dev_inject_plugin {"dir": "D:/dev/my-plugin"}

The README states that the injection takes effect immediately, and you will see the host tool in the next step; if the plugin declares a client, the UI will also be scanned.

3. Development iteration
Modify code → build. It will automatically reload in ~1.5 seconds; you can also manually trigger:

dev_reload_package

After stabilization, use dev_stage_promote to move the staged tools to the official schema.

4. Go from scaffolding to injection

dev_scaffold_plugin {"dir": "D:/dev/my-plugin", "name": "my-plugin", "form": "daemon-loop", "description": "..."}
dev_build_plugin {"dir": "D:/dev/my-plugin"}
dev_inject_plugin {"dir": "D:/dev/my-plugin"}

Valid values for form also include toolkit, ui-panel, and hybrid.

5. Uninstallation

dev_uninject_plugin

The parameter is the package name substring. After uninstallation, tools / listeners / routes / client tables should be cleared, no restart required.

Applicable Scenarios and Notes¶

It is suitable for the following groups: developers building complete DSH plugin packages locally, users who need to verify host+UI without restarting, and users who want to hot-mount finished modules into a running web profile. It is not suitable for scenarios where you only want to modify official configurations, or only need single-file small tools generated in conversations — use dsh-evolve for those scenarios.

Please note the following points, all of which can be found in the README, INSTALL.md, or SPEC:
1. Permissions and Source. The plugin runs with the same permissions as the current dsh process, and can read/write profiles, write patches, and modify node_modules junctions. The community directory is not an official store, please review the source code and license before installing.
2. Profile Must Match. Tools are mounted to the web profile. If --profile web does not match the running profile, the dev_* tools will not appear.
3. Outdated Package Name Documentation. package.json and the repository’s cordis.patch.yml use @dsh-external/dsh-super-injector; some examples in INSTALL.md still write @yjh051108/dsh-super-injector. Use the name field in package.json as the standard for assembly, uninstallation, and junction paths.
4. Resources Must Be Mounted with ctx.effect. Cleanup relies on fiber disposal during hot reload or uninstallation. Bare registrations will leave zombie tools / routes, and may report duplicate / already registered during reload.
5. Plugin Package Must Include Dependency Resolution. import '@deepseek-ai/dsh-tools' in lib/ will resolve from the package’s own node_modules; the client UI needs to be built separately with npm run build:client, and the output is lib/client.js. Client operations must use the full package name, short names will fail silently.
6. cordis.patch.yml Can Only Have One Top-Level Value. Either [], or a list of - id: / - insert: entries. Mixing the two will cause YAML parsing failure and break all assembly. Duplicate entries with the same ID will trigger duplicate loader entry id, preventing dsh from starting. Starting from v0.3.3, writePatch performs idempotent deduplication by ID; if the service crashes, you can use node scripts/fix-patch.mjs in the extracted directory (does not depend on a running dsh instance).
7. peerDependencies Are Range Declarations: @deepseek-ai/dsh-tools: >=0.0.1-rc <2, cordis: >=4.0.0-rc <5. The maintainer claims compatibility with service renames: webServer (formerly httpServer), compaction (formerly compact). DSH is still in developer preview, and core APIs will change, so you should run dev_self_test again after upgrading.
8. The review scores, “zero crash” stress test, and 8/8 self-test mentioned in the README are all self-reported by the maintainer in the repository, not third-party reproduction reports.

Summary¶

dsh-super-injector fills the runtime layer below the official bundle assembly: injection, hot reload, staging promotion, uninstallation, and route self-healing. v0.3.0 consolidated self-reload to the DSH 0.1.0-rc.6 REPLACE contract, and v0.3.3 added Windows/macOS assembly and self-contained host packaging. The main workflow is to install the bootloader via the official path first, then run dev_inject_plugin for local plugin packages.

Community Directory: https://deepseek-harness-plugin.com/zh-CN/plugins/dsh-super-injector/
GitHub: https://github.com/yjh051108/dsh-super-injector
Releases: https://github.com/yjh051108/dsh-super-injector/releases

Inject Local Plugins into DeepSeek Harness Runtime with dsh-super-injector