dsh plugin add re-registers plugins already loaded by cordis.patch.yml, crashing web boot with duplicate loader entry id

[taonokenshin]

Environment

• dsh (npm install of the 2026-08 build running dsh web), Windows 11, web profile.
• The profile already loaded 10 community plugins the "manual" way: each in package.json dependencies (GitHub refs) plus an explicit - insert: row in cordis.patch.yml (e.g. id: session-cleaner, id: dsh-pdf, id: dsh-skin, ...).
• Many of these community packages ship a dsh.bundle.patch (package.json → dsh.bundle.patch → ./cordis.patch.yml).

Symptom (100% reproducible)

Running dsh plugin --profile web add dsh-vision-router (or even dsh plugin list, per later diagnosis) rewrites package.json so that every dependency that declares dsh.bundle.patch is appended to dsh.profile.bundles. On the next boot, those plugins are registered twice — once from the new bundle layer, once from the pre-existing cordis.patch.yml rows — and the whole web backend fails to start:

Error: dsh: plugin tree failed to load: failed to apply loader entry include (cordis:include): duplicate loader entry id: session-cleaner

Removing just session-cleaner does not help; the next plugin (dsh-pdf, dsh-skin, …) then collides in turn. The web server never reaches listen — the profile appears "completely down" (no login page).

Root cause

dsh plugin add/list/update collects every dependency with a dsh.bundle.patch into dsh.profile.bundles without knowing that those same plugins are already inserted via cordis.patch.yml. The two loading mechanisms (bundle layer vs. manual patch layer) are not deduplicated by id, so the loader throws duplicate loader entry id instead of "last layer overrides first".

Workaround (keeps existing plugins intact)

Do not use the dsh plugin command at all on a profile that already loads plugins manually. Install the new plugin the same way as the existing ones:

1. add "<plugin>": "^<version>" to package.json dependencies;
2. add an - id: ... / name: ... row under the existing - insert: list in cordis.patch.yml;
3. run plain pnpm install.

This installed dsh-vision-router@1.5.2 cleanly; dsh --dump-config confirms each plugin appears exactly once.

Suggested fix

Any of the following would prevent this class of outage:

1. dsh plugin should detect rows already present in cordis.patch.yml (or already composed by an earlier layer) and skip/warn instead of appending a duplicate bundle.
2. Loader-level dedupe by id across bundle layers and patch layers — later layers override earlier ones (which the bundle patch comments already claim is the intended semantics).
3. At minimum, dsh plugin add/list should print a clear warning when it is about to add bundles that duplicate manually-declared plugin rows.

Evidence bundle

• package.json before/after dsh plugin add (the command appended the 8 dsh.bundle.patch packages into dsh.profile.bundles).
• cordis.patch.yml (unchanged, already containing the same plugin ids).
• Boot error log (duplicate loader entry id: session-cleaner).
• Backup files (*.pre-vision-rollback-20260818-000422) from the rollback.
  Available on request.

[argszero]

Verified on rc.7 (99f6f02fec) — this is the 5th report in the plugin-reconcile family, and it's the cleanest reproduction of the family's #2 mechanism to date (100% repro, rollback evidence, workaround). Your root cause is exact; the promote path still has no dedup:

1. Confirmed at source. apps/cli/src/plugin.ts:63-89 (reconcileBundles): the first loop pushes every dependency declaring dsh.bundle into dsh.profile.bundles with zero awareness of cordis.patch.yml rows — plugins.push(packageName) (:70) when isBundle && !plugins.includes(packageName) only checks the bundle list, never the manual patch layer. On next boot, the loader composes bundle layer + user patch layer and throws duplicate loader entry id (my #1404 verified the same throw at vendor/loader/src/config/group.ts:64). Your --dump-config observation (each plugin once) vs boot crash is the family's recurring "dump-vs-runtime drift" signature.

2. Family lineage — this is trigger class #2, now with the fullest evidence. The reconcile family now has 5 reports across 3 mechanisms:

• #1 promotion of pre-existing bundle deps → duplicate loader entry id (dsh plugin add promotes pre-existing bundle-declaring deps into the bundle stack and breaks the next boot with "duplicate loader entry id" #1404 moonquake2004, macOS rc.6; `dsh plugin add` re-registers plugins already loaded by `cordis.patch.yml`, crashing web boot with `duplicate loader entry id` #2889 you, Windows, 100% repro + workaround + evidence bundle);
• #3 hot re-apply "tool already registered" + stale module cache (Hot re-apply of an in-place updated plugin package fails with tool "X" already registered; module cache serves stale code #1610 xuhurdern-beep);
• #4 shared-object mutation residue → silent disable after ~3s (Third-party bundle plugins are silently disabled ~3s after boot (insert objects mutated by fiber disposal, HMR recompose persists it) #2854 LunaRime — loader writes disabled=true onto the shared patch insert object; I verified the one-line clone fix at vendor/include/src/index.ts:94);
• #1b unresolvable bundle silently spliced ([Bug] plugin install reports success but silently disables an unresolved profile bundle #1377 haihaihaipa).
  Common root: the reconcile is state-based and blind — it can't see how a dependency is loaded (bundle layer vs manual patch layer), and hot re-apply can't verify clean withdrawal.

3. Your suggested fix #2 is the correct one — loader-level dedupe by id across layers, later wins. This matches the bundle-patch comments' own claimed semantics ("last layer overrides first" per vendor/include/src/index.ts:97-99), and it fixes the whole class at the composition point rather than patching each dsh plugin path. Two sub-points:

• The dedupe must compare resolved entry ids, not package names — the same package can insert multiple ids, and two different packages can insert the same id;
• Even with dedupe, a warning (your #3) at dsh plugin add/list time when it detects a bundle whose ids already exist in cordis.patch.yml would catch the common case early with a clear message.

4. Your workaround is exactly right — install manually (package.json dep + cordis.patch.yml row + pnpm install), never dsh plugin add on a profile that already loads plugins manually. That's the safe path until the loader-level dedupe lands.

5. Tie-in with #2854: your fix #2 (dedupe by id at compose) and #2854's fix (clone insert objects at applyEntryPatches) are complementary — dedupe prevents the double-registration crash, cloning prevents the silent-disable mutation. Both are one-line-to-small changes at vendor/include/src/index.ts. If you want, I can consolidate all three proposed fixes (dedupe-by-id + clone-insert + warn-on-duplicate) into a single patch outline for the maintainers — the family now has enough field data to justify it.

Excellent evidence bundle — the before/after package.json, the unchanged cordis.patch.yml, and the boot error together make this unambiguous.