DSH plugin installed but not active: missing dsh.bundle and inject errors

A DSH plugin that installs but never activates comes from two missing declarations: no dsh.bundle manifest (so dsh plugin add installs it as a plain dependency that never loads) or source code lacking an inject declaration (so it throws cannot get property ... without inject). The first needs the author to add the manifest, the second is a plugin bug; on the user side the fastest move is switching to a published build on DSH Plugin Hub.

DSH plugin installed but not active: the two errors and the symptom

The symptom is "installs, does not activate": dsh plugin add exits normally and the package is in the dependency list, but the plugin capability never appears — or loading throws without inject. The two messages (source):

1. Installed but inactive: the terminal says the package is being installed "as a plain dependency, not a profile layer" (declares no dsh.bundle); no capability shows up — the package never declared dsh.bundle, so the host does not treat it as a plugin;
2. cannot get property "systemPrompt" without inject: the code reads systemPrompt or another service before declaring the dependency, and the Cordis reflection layer throws immediately (source);
3. Judgment: the first is a package format problem (missing manifest), the second is a code bug (missing declaration) — both make the plugin "installed but useless".

Why DSH plugin does not activate: missing dsh.bundle and inject declarations

Two root causes: the package lacks the dsh.bundle manifest (a plugin must declare its config layer to be mounted into the host), and the source reads a service without declaring inject (so the host injection never arrives). In detail:

1. No manifest, no layer: the official publishing docs define that a bundle must declare dsh.bundle in package.json and ship cordis.patch.yml; a package without the declaration can be installed, but only as a plain dependency, activating no layer (source);
2. No inject, no service: Cordis requires declare-then-use — code calling ctx.systemPrompt without inject: ["systemPrompt"] makes the reflection layer throw without inject (source);
3. Neither is user-fixable: the first needs the author to change the package declaration and republish, the second needs an author code fix.

Fix for authors: add the dsh.bundle manifest, add inject declarations, verify

If you are the plugin author, follow add-manifest → add-declaration → reinstall; if you are a user, skip to the next section and switch to a published build. Author-side steps:

1. Add the dsh.bundle manifest — create cordis.patch.yml in the package defining the plugin config rows to insert or override, then declare the reference in package.json:
   json

   {
     "dsh": {
       "bundle": { "patch": "cordis.patch.yml" }
     }
   }
   

   Rebuild and publish; only when dsh plugin add sees the dsh.bundle declaration does it append the package to the profile's bundles layer (source);
2. Add inject declarations — find the code that reads ctx.systemPrompt (or other services) and declare the dependency in the plugin config:
   yaml

   inject: ["systemPrompt"]
   

   or the equivalent ctx.inject() form, declaring before use (source);
3. Reinstall and verify — run dsh plugin --profile web remove <package>, re-add, restart the host, and confirm the layer activates and without inject no longer appears.

User side: switch DSH plugin to a published build on DSH Plugin Hub

Users cannot add the manifest for the author — first go back to the DSH Plugin Hub store and switch to an official or published build, while reporting the error to the author. Steps:

1. Open Settings → Plugin Market (DSH Plugin Hub) and search the same plugin name for a published/verified build;
2. If one exists, uninstall the current git-sourced install and install the published build from the hub — hub entries are curated, so missing-declaration problems are rarer;
3. Report the exact declares no dsh.bundle or cannot get property ... without inject message to the author, along with your dsh version and the install command;
4. If the plugin never activates and no alternative exists on the hub, disable it first so it does not affect other features, and wait for the author's fix.

How to verify a DSH plugin activation fix: bundle layer, inject declaration, and capability

Three checks confirm the fix: the plugin is really in the bundle layer, without inject no longer appears, and the plugin capability works in the UI — only when all three pass is it activated. In order:

1. Check the plugin is in the installed list:

   bash

   dsh plugin --profile web list
   

   The package name appearing means it is installed into the current profile; if it is absent, the install did not finish — reinstall per the fix section.

2. Check the bundle declaration (author-side self-check) — confirm the plugin's package.json points at the patch file:

   bash

   grep -A3 '"dsh"' <plugin-directory>/package.json
   

   Output containing bundle.patch pointing at cordis.patch.yml means the manifest is complete; without that block the package still lacks dsh.bundle.

3. Restart the host and watch for layer activation:

   bash

   dsh web
   

   The startup log shows the plugin's bundle layer loading and no cannot get property ... without inject — the declaration problem is gone.

4. Verify the capability in the UI — the commands/panels/config entries the plugin provides appear and work in the Web UI, meaning it is really active.

5. Observe over time — using the plugin for a while with no without inject-style errors closes the loop.

Notes: DSH plugin — check for the no dsh.bundle hint first

1. "Installed but inactive" — first check the terminal for the no dsh.bundle hint; if present it is a missing manifest, so do not keep reinstalling.
2. without inject is a plugin bug — do not try to bypass it with host config; sending the error to the author is the fastest route.
3. Packages installed straight from git+https://... sources are the most likely to lack declarations; prefer npm-distributed published builds.
4. The DSH Plugin Hub plugin page shows source and version — check whether an entry is a verified published build before installing.
5. See install error troubleshooting for other DeepSeek Harness install issues.

Sources: dshbase troubleshooting, DeepSeek Harness plugin publishing docs, cordis/reflect.ts