[Bug] Tool calls fail with "Cannot read properties of undefined (reading prepare)" after pnpm install in a profile

[wsxwj123]

Summary

Every tool call in every session fails with Cannot read properties of undefined (reading 'prepare') after running pnpm install inside a profile directory. Root cause: @deepseek-ai/dsh-tools gets materialized twice — once in the installation tree, once in the profile's node_modules — which splits its module-level scheduler Symbol into two distinct objects.

Environment

• @deepseek-ai/dsh@0.1.0-rc.6, installed globally via npm i -g @deepseek-ai/dsh
• Profile: web, with out-of-tree plugins added via dsh plugin add / pnpm install
• macOS (darwin), Node 22

Reproduction

1. Install dsh globally.
2. Use a profile (e.g. web) and add any out-of-tree plugin that hard-depends on @deepseek-ai/dsh-tools (e.g. dsh-better-sidebar, @omdsh-dev/dsh-genui, @dsh-external/dsh-automation).
3. Run pnpm install inside the profile directory.
4. Start a session and ask the agent to run any tool (pwd).

Observed behavior

The turn/end event records:

{"reason":{"kind":"error","error":{"message":"Cannot read properties of undefined (reading 'prepare')","code":"UNKNOWN"}}}

Every tool call dies at scheduler dispatch, for all sessions.

Root cause

dsh-agent-loop reaches the tool scheduler through a module-level Symbol:

// dsh-agent-loop/lib/index.js:193
const prepared = await ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(call.exec);

TOOL_RUNTIME_SCHEDULER is Symbol("@deepseek-ai/dsh-tools.scheduler") (dsh-tools/lib/index.js:2409). It must be the same object everywhere in the process.

The flat fallback ~/.dsh/profiles/node_modules (maintained by healProfilesModuleFallback) correctly symlinks each @deepseek-ai/* package back to the installation tree, keeping the symbol a singleton — as long as the profile has no local materialization.

Running pnpm install inside a profile (which dsh plugin forwards to pnpm) materializes @deepseek-ai/dsh-tools and other in-box packages as physical copies under ~/.dsh/profiles/<name>/node_modules/@deepseek-ai/. Any out-of-tree plugin that hard-depends on @deepseek-ai/dsh-tools then resolves to this profile-local copy, whose Symbol is a different object from the installation tree's.

Result: dsh-agent-loop (installation tree) uses symbol A to look up ctx.tools[symbolA], but the profile-local dsh-tools copy produced symbol B, so the lookup yields undefined and .prepare throws.

Direct proof (both copies at 0.1.0-rc.6, byte-identical contents):

import A from '<install>/node_modules/@deepseek-ai/dsh-tools/lib/index.js';
import B from '<home>/profiles/web/node_modules/@deepseek-ai/dsh-tools/lib/index.js';
A.TOOL_RUNTIME_SCHEDULER === B.TOOL_RUNTIME_SCHEDULER; // false

Why this is a design bug rather than a plugin bug

• The scheduler key is a module-level Symbol with no guarantee against multiple copies.
• dsh plugin forwards to pnpm, and pnpm install materializes in-box @deepseek-ai/* packages into the profile node_modules, breaking the singleton assumption.
• The shipped web profile manifest itself lists @deepseek-ai/dsh-tools in dependencies, so this reproduces even with zero third-party plugins, as long as pnpm install is run in the profile.
• The failure surfaces as an opaque Cannot read properties of undefined with no hint about the duplicate copy.

Suggested fix direction

1. Make the scheduler key robust to duplicate copies (e.g. Symbol.for("<well-known-key>"), or a plain string key), or
2. Ensure out-of-tree plugins always resolve in-box @deepseek-ai/* packages to the installation tree (declare them as peerDependencies/external in the profile build, or dedupe them back to the fallback symlink), or
3. At minimum, guard the ctx.tools[TOOL_RUNTIME_SCHEDULER] lookup and emit a clear diagnostic like "multiple copies of @deepseek-ai/dsh-tools detected; remove profile-local @deepseek-ai packages and re-run".

[wsxwj123]

Follow-up on the same root cause — this explains a second, downstream symptom.

The Symbol split did not just break tool dispatch; it also left corrupt records in the session history. In dsh-agent-loop's startCall (lib/index.js), appendToolCall(...) runs before the scheduler lookup:

callSeqs[index] = appendToolCall(session, turn, step, call.block);  // persisted first
started++;
const prepared = await ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(call.exec); // throws here

So every tool call that hit undefined.prepare persisted a tool/call event with no matching tool/result. In our session that left 5 orphan tool/call events (4 × cordis_*, 1 × todo_write), each immediately followed by the undefined.prepare error.

Consequences:

• A local OpenAI-compatible endpoint (codexlocal, api: openai-completions) does not validate the tool_calls → tool pairing, so the orphans are tolerated.
• The official DeepSeek endpoint validates it strictly and rejects the request:
  An assistant message with 'tool_calls' must be followed by tool messages responding to each 'tool_call_id'. (INVALID_REQUEST, 400)

So the two symptoms (undefined.prepare on one provider, INVALID_REQUEST on another) are the same bug: the first is the split-symbol crash, the second is the orphaned history it leaves behind, which only surfaces when switching to a stricter provider.

Additional fixes for the list:

• When prepare/dispatch throws, roll back the already-appended tool/call (or append a synthetic error tool/result), so a crash never leaves an unpaired tool_calls message.
• Make serializeMessages defensively drop (or pair) orphan tool-call blocks instead of emitting wire messages the API must reject.

[heerxingen]

我的设备上也遇到了相同的问题，让D老师看过上面的分析后写了一个给Windows设计的修复脚本（只在Windows11+pwsh 7测试过可用，pwsh 5大概会因为编码问题报错。。没试过）：

dsh-fix.ps1.txt

[Electricitysheep]

工具调用类报错（含流式下工具名丢失/description 字段 required 死循环）我们在 FAQ 和第 8 章整理了根因与规避，可对照排查：https://github.com/Electricitysheep/dsh-handbook/blob/main/docs/faq.md

[Electricitysheep]

@deepseek-ai/dsh-tools 被 materialize 两次（profile pnpm install 后）——这和"插件装在哪决定依赖解析"是同一机制：dsh 的扁平兜底目录（$DSH_HOME/profiles/node_modules 软链接）让 Node 在 profile 内可解析到宿主包，但 profile 里再 install 会生成第二份。

完整机制 + 规避（link 开发依赖声明/版本线锁定）见手册第 3 章：https://github.com/Electricitysheep/dsh-handbook/blob/main/docs/03-profiles.md