Fix DSH plugin crash: duplicate loader entry and Failed to load plugins

A crashing DSH plugin shows two errors: duplicate loader entry id from a bundle dependency hoisted twice (colliding entry ids), and Failed to load plugins when a plugin fails to mount at startup. Remove the duplicate from the profile's bundle config for the first; disable plugins one by one to find the culprit for the second. Handle it in four steps: clean and reinstall, check dependency conflicts, disable one by one, roll back to a stable version.

DSH plugin crash: the two error texts — a duplicate loader entry and a fatal mount failure

duplicate loader entry id is the loader rejecting a duplicate entry while building the bundle stack; Failed to load plugins is a plugin failing to mount at startup with no recovery action. The two messages (source):

1. duplicate loader entry id: <package> — the loader refuses at startup or install: a dependency that already declares a bundle was hoisted into the bundle stack again and the entry ids collide (source);
2. Failed to load plugins — startup reaches the mount phase and fails, the UI enters a fatal screen with no recovery button;
3. The pattern: the first usually appears after installing a new plugin, the second after a batch of upgrades/reinstalls — both make the host start abnormally.

Why DSH plugins crash: dependencies hoisted twice, mount exception

Two roots: a dependency hoisted twice creates a duplicate entry in the bundle stack, and a plugin throwing during mount takes the whole startup down. In detail:

1. Hoisted twice: dsh plugin add promotes a dependency that already declares a bundle into the bundle stack again, producing a duplicate entry id (source) — common when plugin A and plugin B share the same bundle dependency and both declare the layer;
2. Mount exception: a plugin throws during the startup mount phase (missing dependency, incompatible version, initialization failure) and the UI offers no recovery (source);
3. Combined scenario: after a batch reinstall the dependency tree changes, which can both collide duplicate entries and invalidate a plugin's mount prerequisites.

Fix DSH plugin crash: clean and reinstall, check conflicts, disable one by one, roll back

Clear duplicates first, then isolate the culprit: clean up and reinstall, inspect the dependency tree, disable plugins one at a time, roll back to a stable version. Step by step:

1. Clean and reinstall — remove the most recently installed/updated plugins first, then add them back one at a time:
   bash

   dsh plugin --profile web remove <the plugin added most recently>
   dsh plugin --profile web add <the same plugin>
   

   Restart the host — a clean start means the duplicate entry is gone;
2. Check dependency conflicts (for duplicate loader entry id) — open the profile's package.json (~/.dsh/profiles/<name>/package.json) and inspect dsh.profile.bundles for duplicates: if a duplicate exists, delete it and keep one copy, save, then run pnpm install to sync dependencies;
3. Disable one by one (for Failed to load plugins) — move all plugins out of the profile and restart; a working start means it is a mount problem. Then add one plugin back and restart each time — the one that crashes the host when re-added is the culprit (source);
4. Roll back to a stable version — uninstall the crashing version and install the previously stable one (dsh plugin --profile web add <package>@<old-version>), or wait for the author's fixed release;
5. Verify — restart the host: a normal UI with no fatal screen and no duplicate loader entry id means it is fixed.

How to verify a DSH plugin crash fix: clean bundle stack, per-plugin regression, and stability

Three gates confirm the fix: the bundle config has no duplicates, the host starts without a fatal screen, and plugins come back one by one without crashing — only then is it safe for real use. In order:

1. Confirm the bundle stack has no duplicates — inspect the profile's bundle declaration:

   bash

   cat ~/.dsh/profiles/web/package.json | grep -A6 '"bundles"'
   

   Each package appearing once in the bundles list means it is clean; a duplicate means the conflict is still there — back to step 2 of the fix section.

2. Restart the host and confirm no fatal screen:

   bash

   dsh web
   

   The startup log reaches the Web server listening line without duplicate loader entry id or Failed to load plugins, and the UI opens — the second gate passes.

3. Add plugins back one at a time — add one plugin and restart to verify each time:

   bash

   dsh plugin --profile web add <plugin>
   

   If the host does not crash, add the next one; the plugin that crashes the host when re-added is the culprit (back to step 3 of the fix section).

4. Check the current install list (to confirm the regression scope):

   bash

   dsh plugin --profile web list
   

   The list matches your expectation with no leftover entries, meaning the cleanup is complete.

5. Stability observation to close — use the host continuously for a while (run a few tasks, restart once or twice) with no crashes; since you backed up the profile config first (note 4 of the fix section), a misstep can be rolled back quickly.

Notes: DSH plugin — clean first, then isolate the culprit

1. For duplicate loader entry id, check dsh.profile.bundles for duplicates first — do not reinstall everything blindly.
2. For Failed to load plugins, use the add-one-back-at-a-time method to find the culprit — one plugin per restart.
3. After isolating the crashing plugin, disable it and either wait for the author's fix or find an alternative on DSH Plugin Hub — hub plugin pages track version iteration so you can follow the fix progress.
4. Back up the profile config (copy ~/.dsh/profiles/<name>/) before reinstalling to avoid losing config on a misstep.
5. See install error troubleshooting for other DeepSeek Harness install errors.

Sources: dshbase troubleshooting, DeepSeek Harness loader source, DeepSeek Harness plugin publishing docs