Third-party plugin pins an old @deepseek-ai/dsh-tools as a runtime dependency: install silently overwrites host core packages with no error at the time, crash on next startup

[jackdizhu]

Hi all — I hit an issue on the desktop profile (nightly channel). After searching, I can confirm it belongs to the same family as #1486 / #1697 / #2731, but with a different presentation, so I'm sharing it here for reference. Please correct me if any part of my analysis is off.

What happened

After installing a third-party plugin from the registry (dsh plugin add), three packages appeared at the top level of the profile's node_modules/@deepseek-ai/: dsh-tools, dsh-brand and dsh-util-values, all at version 0.1.2-rc.1, inconsistent with the host core (nightly, roughly the 0.2.0-rc.x line).

The problem has two phases, which is exactly what made it so hard to trace:

• At install time (silent): the install command completed normally with zero warnings, and the running host (hot-reloaded) kept working fine — tool calls included. In reality the host core packages had already been silently overwritten with older copies.
• On next startup (blast): only after restarting the host did it crash and fail to boot. There is a "seems totally fine" window between the install action and the crash, which makes it very hard to connect the failure back to the last plugin install.

I only located the cause by inspecting the profile directory, finding the three overwritten packages, and manually renaming them aside (isolation) to get the host booting again.

Trigger condition

The plugin declares the host core package as a direct dependency with an exact pin in its package.json:

"dependencies": { "@deepseek-ai/dsh-tools": "0.1.2-rc.1" }

A useful contrast: transitive deps of the same tree whose versions are compatible with the host (schemastery, cosmokit) were left untouched; exactly the set that is "really installed + conflicts with the host version" got replaced.

How this differs from the existing discussions

#1486/#1697/#2731 describe the same-version duplicate case: install succeeds, boot is fine, and the failure hits at runtime — every tool call throws Cannot read properties of undefined (reading 'prepare'). This case is the version-skew variant: silent at install time (hot-reloaded host keeps running), failure deferred to the next startup, where the host fails to boot at all. The common gap is that both variants warn nothing at install time — the risk is injected the moment the install completes.

Directions to consider (already raised in prior discussions; adding a fresh datapoint)

• Enforce the host core package set (@deepseek-ai/*) as external / peer-only at the loader level, so a plugin misdeclaring them simply cannot be materialized into the profile;
• Install-time audit: reject the install, or at least warn explicitly, when a plugin dependency would change the version of a host core package (a warning here would have surfaced this before the crash-on-restart);
• Docs: clearly tell plugin authors that core packages must be peerDependencies.

Current workaround

I've switched the plugin to a link: install (pnpm doesn't resolve a link target's dependencies, so the pollution no longer happens) and manually quarantined the three overwritten packages.

Thanks!

[argszero]

Thanks for writing this up with the phase split spelled out — the "silent at install, fatal at next start" shape is the part earlier reports kept losing, and it is what makes this diagnosable at all. Your reading of the mechanism holds. Below is what I can pin to source at 687f282e86 (0.2.1-rc.2), three places worth correcting or adding, and one honest limit on the plugin-side mitigation.

1. Why install warns nothing: the check exists, it asks a different question

There already is an install-time preflight, and it reads exactly the manifest you found. runProfilePnpm collects the named specs, resolves each manifest, runs evaluatePluginCompatibility and refuses the whole run before pnpm executes (packages/boot/plugin-manager/src/operations.ts:334-352, with the rejection path at :325 restoring package.json and pnpm-lock.yaml).

The blindness is one field up, in the evaluator: unmetRequirements reads engines.dsh and, only when that is absent, the @deepseek-ai/dsh* entries of peerDependencies (packages/boot/app-boot/src/plugin-compatibility.ts:55-74). dependencies is never read — not for version, not for presence. Your "@deepseek-ai/dsh-tools": "0.1.2-rc.1" is therefore not "unmet"; it is invisible, and the preflight passes because it was asked whether the plugin declares a requirement the runtime fails, not whether it declares a copy.

That distinction is worth keeping: the compatibility channel is about ranges. This defect is about a dependency field, and it needs its own rule, not a wider range check.

2. The copy is not merely present — it wins resolution

This is the half I would add to your analysis, because it explains why one stale directory breaks a whole process rather than one plugin.

For an importer located inside the profile directory, routeScoped builds its candidate list from the profile's own node_modules first, and if anything is there it selects it and returns — before it ever consults the installation's entry (packages/boot/app-boot/src/profile-resolution/resolver.ts:588-616; the candidate test at :283-292 is only "a directory exists at that name", with no version or scope consideration). The installation's copy is the fallback, not the default.

And this precedence is deliberate, not an accident: packages/boot/app-boot/tests/profile-resolution.spec.ts:534 — "keeps a profile-local package ahead of the resolution" — pins a profile-local @deepseek-ai/dsh-core at a different version beating the installation copy in both ESM and CJS. So the runtime does not merely tolerate the second copy; it prefers it, by contract.

Your two phases then follow mechanically: at install time the rows were already imported and cached, so nothing re-reads them (hence "keeps working"); at the next start the same import resolves through the profile layer and lands on the old directory (hence the crash). It also explains why link: saves you — pnpm does not materialize a link target's dependencies, so no physical copy is created. That workaround is sound but it holds only while the entry stays a link: spec.

3. One thing worth measuring on your side

resolveBundleDir carries an explicit contract: the installation is tried first so an in-box bundle "always comes from the same installation as the running dsh, never from a profile-local copy" (packages/boot/app-boot/src/profile.ts:702-714). That guarantee covers the bundle's own directory — but the rows inside the bundle's patch layer are imported from the profile layer, so they are not obviously protected by it.

So: is the failing import in your boot stderr a bundle/plugin row, or the host's own module graph? If it is a row, then §2's preference is escaping a contract the bundle loader believes it enforces, and the upstream fix has a second, sharper edge than the install-time audit. I do not want to assert that from reading alone — your stderr decides it.

4. Where a fix can go, cheapest first

(a) Install-time audit — the right place, and small. The manifest is already read at operations.ts:340-345; a rule beside unmetRequirements — a manifest listing @deepseek-ai/dsh or @deepseek-ai/dsh-* under dependencies/optionalDependencies is reported through the existing compatibility channel — gets you the warning you are asking for at the one moment the risk is injected. It has to refuse rather than warn: by the time a post-install warning could be printed, pnpm has already materialized the copy. The refusal path is the same one already used for an incompatible version, so the profile is restored cleanly.

(b) Startup skew diagnostic — catches manifests installed by something other than dsh plugin add (hand-run pnpm add, a profile copied from another machine). The data already exists in one table: RuntimeResolutionEntry carries name, packageDir, version and scope, and entries is documented as "installation-scope entries followed by profile-scope entries in precedence order" (profile.ts:125-137, :157). Comparing same-name entries across scopes for @deepseek-ai/* is O(entries) at launch, no filesystem walk, and it can name the profile manifest that declared the name.

(c) Docs — your third suggestion has no counterargument. The rule does exist as a gate for in-repo packages (scripts/check-workspace-constraints.ts:513-518 requires @deepseek-ai/cordis in both peerDependencies and devDependencies), but there is no author-facing statement anywhere in docs/ telling a third-party plugin author that harness packages are peer-only. The gate cannot reach a published third-party manifest; only text can.

What I would not do is reserve @deepseek-ai/* names at resolution. Test :534 above says local precedence is intentional; removing it to compensate for a misdeclared manifest trades a supported behaviour for a workaround.

5. Existing plugin-side coverage, with its limit stated plainly

@argszero/cordis-plugin-profile-duplicate-doctor (npm, 0.1.0) does the attribution half: on every start it walks <profile>/node_modules, compares every name the installation also owns by realpath, and treats a distinct directory as a second copy — reporting both versions, both directories, and the manifest whose dependencies declared it. For @deepseek-ai/* it labels the finding identity, because that is the class where two copies cannot see each other. That is the manual inspection you did by hand (finding the three packages, renaming them aside), as one log line plus one advisory per agent.

The limit, and it matters for your case: it is a plugin, so it can only report in a start that succeeds. Your fatal-skew variant fails precisely in that start, so this does not prevent it — it names the culprit on the restarts that do come up, and it cannot remove the copy. That is why §4(a) carries more weight than the plugin does: prevention has to happen before pnpm runs.

6. Two questions

1. Is the profile on the hoisted linker? Three plugin-transitive packages appearing at the profile's top-level node_modules/@deepseek-ai/ is the hoisted layout; under the default isolated linker this shape should not appear, and the answer changes what an audit has to compare.
2. Does the profile manifest itself list @deepseek-ai/dsh-tools (i.e. it arrives through your bundle entries)? If so the mechanism is a version substitution of an existing declaration — pnpm had to satisfy one exact pin against the range already there — which is a strictly narrower fix than "a new core name appeared", and it is the difference between auditing new names and auditing changed versions.

[jackdizhu]

Thanks @argszero — this is exactly the source-level grounding I couldn't do myself. Answers to your two questions, plus one status update:

Q1 — linker: Yes, hoisted. The generated pnpm-workspace.yaml has nodeLinker: hoisted with autoInstallPeers: false. So the peer path exists (host provides the core), but the plugin's dependencies were still hoisted to the profile top level.

Q2 — new names, not version substitution: The profile manifest never declared @deepseek-ai/dsh-tools — its dependencies contain no @deepseek-ai/* entries at all (the dsh.profile.bundles list references bundle names only). The trio arrived as brand-new top-level names via the plugin's transitive tree, each materialized at the plugin's exact pin. So per your framing this is the "a new core name appeared" case: the audit axis would be a new @deepseek-ai/* name appearing under profile scope, keyed on dependencies/optionalDependencies per your §4(a).

On §3 (stderr): I have to be upfront that I cannot provide this — the desktop app crashed at boot without preserved stderr, and nothing matching survives under ~/.dsh. I can't yet adjudicate "bundle/plugin row vs the host's own module graph." If it recurs I'll reproduce with a terminal launch to capture the failing import path.

Plugin-side status (new datapoint): the plugin that triggered this has been fixed in my fork — dsh-wait-subagent v1.3.0 removes the exact-pinned dependencies entry and declares @deepseek-ai/dsh-tools (and @deepseek-ai/dsh-llm) as peerDependencies with a wide range: package.json

State after the fix (installed via link:): profile top-level node_modules/@deepseek-ai/ holds only cosmokit and schemastery (compatible, untouched); pnpm-lock.yaml has zero dsh-tools references and the virtual store has no @deepseek-ai/* entries; the host boots and runs normally on 0.2.x. So the peer + host-provided path works end-to-end — but it only removes this one plugin's pollution surface, and the loader gap remains for any future misdeclared manifest. That's why I agree the refuse-at-install audit (§4a) is the load-bearing fix: it must refuse rather than warn, and per Q2 it can trigger on "new installation-scope name in a plugin manifest's dependencies/optionalDependencies".

Also confirming your §5 limit from the field side: our fatal-skew variant is exactly the case the doctor plugin can't cover — no successful start to report in. Attribution on surviving restarts plus refusal before pnpm runs would compose well. And thanks for the :534 pointer — knowing profile-local precedence is contractual settles "host-first resolution" as off the table and puts the weight on install-time refusal plus a startup skew diagnostic.