Tool layer fails with "Cannot read properties of undefined (reading 'prepare')" after installing third-party plugins

[dj1113969731-cloud]

Tool layer fails with "Cannot read properties of undefined (reading 'prepare')" after installing third-party plugins

Environment: Windows 11, @deepseek-ai/dsh@0.1.0-rc.6 (latest), web profile
Severity: High for users who install third-party plugins into a profile

Summary

After installing third-party plugins into the web profile (plugins that depend on
@deepseek-ai/dsh-tools, e.g. dsh-undo, dsh-restart, dsh-mneme, dsh-balance-meter),
every model tool call fails with:

Cannot read properties of undefined (reading 'prepare')

The UI shows 本轮运行失败 (this round failed) for the tool, and the agent loop
breaks. The headless profile works fine.

Repro steps

1. dsh plugin --profile web add <any-plugin-that-depends-on-@deepseek-ai/dsh-tools>
2. Restart dsh web
3. In any session, ask the agent to run a tool (e.g. pwsh / Get-Date)
4. The tool call fails with Cannot read properties of undefined (reading 'prepare')

Root cause

dsh plugin add forwards to pnpm, and pnpm hoists the plugin's transitive
@deepseek-ai/* dependencies into the profile's own node_modules:

profiles/<profile>/node_modules/@deepseek-ai/dsh-tools      <- copy A
.../npm/node_modules/@deepseek-ai/dsh/node_modules/@deepseek-ai/dsh-tools   <- copy B (framework)

Both copies are loaded into the same process, so there are two module
instances of dsh-tools. Each instance has its own local Symbol:

const TOOL_RUNTIME_SCHEDULER = Symbol('@deepseek-ai/dsh-tools.scheduler')

Symbol('x') !== Symbol('x') across module instances. Instrumentation confirmed:

• The ToolRuntime instance behind ctx.tools is constructed by copy A
  (profile copy) — its [TOOL_RUNTIME_SCHEDULER] property is keyed by copy A's symbol.
• dsh-agent-loop imports TOOL_RUNTIME_SCHEDULER from copy B (framework copy),
  so ctx.tools[symbolB] is undefined, and ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(exec)
  throws at runtime.
• Same for cosmokit, dsh-llm, dsh-settings, schemastery — all duplicated.

Suggested fixes (any one would help)

1. Use Symbol.for('@deepseek-ai/dsh-tools.scheduler') (global symbol registry) in
   dsh-tools so the key survives duplicate module instances.
2. Make the scheduler lookup in dsh-agent-loop resilient (fall back when
   ctx.tools[TOOL_RUNTIME_SCHEDULER] is undefined).
3. In the loader / dsh plugin flow, dedupe @deepseek-ai/* packages that already
   exist in the framework install (e.g. prefer the framework copy, or symlink).

Workaround (verified)

Replace version-identical duplicated @deepseek-ai/* packages in
profiles/<profile>/node_modules/@deepseek-ai/ with directory junctions pointing
at the framework copy — Node.js dedupes by realpath, restoring a single module
instance. Note that every subsequent dsh plugin add/remove (pnpm install)
recreates the real copies, so the dedupe must be re-applied after each install.

[moonquake2004]

Excellent root-cause analysis — the dual-module-instance + per-module Symbol mismatch is precise, and I can confirm the mechanism from a sibling case.

This is the third entry in a pattern I've been collecting around dsh plugin add and pnpm's install side effects:

• dsh plugin add promotes pre-existing bundle-declaring deps into the bundle stack and breaks the next boot with "duplicate loader entry id" #1404: dsh plugin add reconciles dsh.profile.bundles by installed state, promoting pre-existing bundle-declaring deps → user-patch insert collision → boot dies with duplicate loader entry id.
• dsh web fails to boot: unresolvable plugin reference in profile patch (cordis.patch.yml) #1197: a file:-installed plugin whose node_modules link vanished leaves a dangling cordis.patch.yml insert → ERR_MODULE_NOT_FOUND at boot.
• Tool layer fails with "Cannot read properties of undefined (reading 'prepare')" after installing third-party plugins #1486 (this one): pnpm hoists transitive @deepseek-ai/* deps into the profile → two module instances → Symbol mismatch → tool layer dies at runtime.

Same root theme: dsh plugin/pnpm mutates the profile's node_modules in ways the loader and runtime don't guard against — duplication, dangling links, or re-hoisting that changes resolution. (My own case, #1404, also involved file: deps like dsh-better-sidebar, so the overlap is not accidental.)

A data point that may help: in my web profile, the same duplicated @deepseek-ai/* packages (dsh-tools, cosmokit, …) do exist inside the pnpm virtual store (.pnpm/node_modules/@deepseek-ai/), pulled in by the dependency trees of installed plugins — but they are not on the runtime load path: the profile's top-level node_modules/@deepseek-ai/ is empty, so bare specifiers from profile plugins resolve through the flat fallback ($DSH_HOME/profiles/node_modules, symlinked to the framework copies) and everything loads as a single instance — tool calls work. So the crash needs the profile copy to be hoisted to the top level (as in your repro), not merely present in the virtual store. Worth noting for anyone checking whether they're affected: check for profiles/<name>/node_modules/@deepseek-ai/<pkg> (top-level), not just .pnpm.

On the fixes: Symbol.for in dsh-tools is the minimal robust fix (and I'd apply it to every Symbol('@deepseek-ai/...') in the framework — cosmokit, dsh-llm, dsh-settings, schemastery per your list). Longer-term, the loader/dsh plugin flow should prevent @deepseek-ai/* duplication altogether (prefer framework copy / dedupe), which is the same direction as #1197's suggestion to make patch-insert resolution symmetric with bundles.

Thanks for the instrumentation — this makes the class of failure much easier to reason about.

[floydbsj-Bai]

我在 Windows + DSH 0.1.0-rc.6 + web profile 环境中复现了相同问题。

安装 dsh-effort-switch 后，新建对话并让模型调用 Read 工具，会立即报：

Cannot read properties of undefined (reading 'prepare')

普通文本回复正常，但 Read、搜索、命令等工具调用都会失败。重启 DSH 和新建对话都不能解决。

我的环境中发现 profile 和 DSH 核心分别加载了两份 @deepseek-ai/dsh-tools，怀疑是重复模块实例导致 TOOL_RUNTIME_SCHEDULER 的 Symbol 不匹配。

附件是实际失败截图。

[moonquake2004]

Thanks for the field confirmation — this is the #1486 mechanism live, and "restart doesn't fix it" matches: the two module instances coexist in the same process regardless of restart, so only removing the duplicate (or the plugin that pulls it in) recovers the tool layer.

Quick fixes, fastest first:

1. dsh plugin --profile web remove dsh-effort-switch (or whatever else pulls a second @deepseek-ai/dsh-tools in) — the tool layer should recover immediately;
2. or the junction workaround from the thread (point the profile's duplicate @deepseek-ai/* at the framework copy) — note it must be re-applied after every pnpm install.

If you want to confirm the condition before touching anything: our offline checker (shared in #1534) has a P5 check for exactly this — node dsh-doctor.mjs --profile web flags top-level profiles/<name>/node_modules/@deepseek-ai/* duplication. One question that would help: in your profile, is the duplicate dsh-tools at the top level of node_modules/@deepseek-ai/, or only inside the plugin's own dependency tree? (Top-level → pnpm hoisted it onto the load path; plugin-only → it's riding the plugin's resolution. Both are the same #1486 mechanism but the fixes differ slightly.)