Plugin-bundled duplicate @deepseek-ai/dsh-tools breaks all tool calls (ctx.tools[TOOL_RUNTIME_SCHEDULER] undefined)

[Tongzzzz]

Summary

After installing a third-party plugin (dsh-computer-use) into the web profile, every tool call in the web UI crashes with:

Cannot read properties of undefined (reading 'prepare')

After the crash, the session is left with a dangling tool/call (no tool/result), so every subsequent turn in that session — and in any session forked/seeded from it — fails with:

An assistant message with 'tool_calls' must be followed by tool messages responding to each 'tool_call_id'. (insufficient tool messages following tool_calls message)  INVALID_REQUEST

Environment

• dsh: 0.1.0-rc.7 (global npm install)
• Node.js: v24.15.0
• macOS (Apple Silicon)
• Profile: web, with third-party plugins installed via dsh plugin / dshmarket

Root cause

TOOL_RUNTIME_SCHEDULER is a module-level Symbol created in @deepseek-ai/dsh-tools:

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

Installing a plugin that depends on @deepseek-ai/dsh-tools (e.g. dsh-computer-use@0.1.0, which bundles @deepseek-ai/dsh-tools@0.1.0-rc.6 as a real dependency under its own node_modules, and other plugins with ^0.1.0-rc.6 peer ranges hoisting an rc.6 copy to $DSH_HOME/profiles/web/node_modules/@deepseek-ai/dsh-tools) results in two physical copies of the dsh-tools module in one process:

1. the core copy (rc.7) used by dsh-agent-loop
2. the profile/plugin copy (rc.6) loaded through the profile's node_modules

Each module instance creates its own unique Symbol, so ctx.tools[TOOL_RUNTIME_SCHEDULER] in dsh-agent-loop resolves to undefined and the first .prepare() call throws:

TypeError: Cannot read properties of undefined (reading 'prepare')
    at startCall (.../@deepseek-ai/dsh-agent-loop/lib/index.js:193:60)
    at fillPool (.../dsh-agent-loop/lib/index.js:233:10)
    at runGroup (.../dsh-agent-loop/lib/index.js:242:9)
    at executeToolCalls (.../dsh-agent-loop/lib/index.js:135:25)
    at ReactLoopAgent.step (.../dsh-agent-loop/lib/index.js:662:32)
    at ReactLoopAgent.turn (.../dsh-agent-loop/lib/index.js:555:22)

Timeline confirms it: tool calls worked until the plugin was installed; removing the plugin and all stray dsh-tools copies from the profile restored normal operation.

Reproduction

1. dsh plugin --profile web add dsh-computer-use (or any plugin that pulls @deepseek-ai/dsh-tools into the profile's node_modules)
2. Start dsh web, open a new session, send any prompt that triggers a tool call (e.g. "list files in the current directory")
3. The turn fails at the first tool call with the prepare TypeError; continuing the session then fails with INVALID_REQUEST

Note: --profile headless is unaffected (no third-party plugin bundles loaded).

Secondary issue: unrecoverable session corruption

When a turn crashes between tool/call and tool/result, the session log keeps a dangling tool call. Because sessions are seeded/forked with their full history (parentSession / seedLength), the corruption propagates to every descendant session and the API rejects every subsequent request. There is no built-in recovery: the user has to abandon the whole session chain (or hand-repair the log). Suggestion: on resume, detect a trailing unanswered tool_calls block and either synthesize an error tool-result or truncate it.

Suggestions

1. Dedupe / externalize core packages for plugins: document that plugins must treat @deepseek-ai/* packages as peer-only, and/or make the plugin loader resolve @deepseek-ai/* imports from the core installation so only one module instance ever exists.
2. Replace the symbol-key lookup with a string key or a service interface that survives duplicate module instances.
3. Installer guard: dsh plugin add could warn/block when a plugin bundles a different version of a core @deepseek-ai/* package than the running harness.

Workaround (for anyone hitting this)

dsh plugin --profile web remove dsh-computer-use   # or the offending plugin
# remove any stray copies:
rm -rf "$DSH_HOME/profiles/web/node_modules/@deepseek-ai/dsh-tools"

then restart dsh web.

[bevinkatti]

The Symbol() explanation makes sense here. One nuance I'd be careful about: switching Symbol(...) to Symbol.for(...) would make the key survive duplicate module instances, but it wouldn't make the duplicated dsh-tools instances themselves safe — any module-level state/singletons could still diverge.

I think the more robust boundary is to make TOOL_RUNTIME_SCHEDULER explicitly host-owned and inject/expose it as a capability/service, with plugins treating @deepseek-ai/dsh-* packages as peer-only. Then the plugin cannot accidentally create a second scheduler registry just by resolving another copy of dsh-tools.

The dangling tool/call is also worth fixing independently. Even if the underlying tool execution throws, the persistence layer should probably have a failure path that guarantees a matching tool result/error before committing the turn. That would prevent one plugin/module-resolution failure from permanently poisoning the session chain and all of its forks.

[argszero]

Verified against rc.7 (99f6f02fec) — this is the 5th field report of a known family, and the first on macOS. More importantly: your root-cause identification is the missing link that explains the 'prepare' crash reports that have been circulating without a cause (#2660 with two victims, plus the dangling-call consequences in #2900/#2661/#3171). The family now has its trigger named.

1. Family confirmation — duplicate-copy symbol crash (5 reports).

• Community plugins resolving a second @deepseek-ai/dsh-tools copy crash the tool scheduler with Cannot read properties of undefined (reading 'prepare') #1337 (Windows, rc.6, hoisted copy) → [Bug] 第三方插件把 @deepseek-ai/dsh-tools/cordis 副本带进 profile 依赖，导致所有会话所有工具调用报 "Cannot read properties of undefined (reading 'prepare')" #1633 (Windows, pollution: top-level core deps in profile package.json) → Windows11系统Pswh工具调用失败导致后续聊天无法进行 #1665 (Windows, pwsh interrupt) → [Bug] 所有工具调用都报 "Cannot read properties of undefined (reading 'prepare')" — ToolRuntime 调度器未注册（rc.6） #1677 (WSL, clean install, packaging-level: dsh-base declaring dsh-tools as a regular dep while tool plugins peer it) → Plugin-bundled duplicate @deepseek-ai/dsh-tools breaks all tool calls (ctx.tools[TOOL_RUNTIME_SCHEDULER] undefined) #3033 (yours, macOS, rc.7, plugin-bundled copy).
• Verified at rc.7: TOOL_RUNTIME_SCHEDULER: unique symbol = Symbol(...) (packages/core/tools/src/index.ts:466); the scheduler is a class-field initializer (:796) so every physical module instance carries its own symbol-keyed registry. Two physical copies of dsh-tools in one process → ctx.tools resolves through the foreign instance → ctx.tools[TOOL_RUNTIME_SCHEDULER] is undefined → undefined.prepare throws at packages/core/agent-loop/src/tool-calls.ts:169 (still no defensive check on rc.7). Your stack trace matches exactly (startCall :193 / fillPool :233 in built lib).
• The macOS angle is the new data point: prior reports were all Windows/pnpm-hoisting; yours shows any second physical copy (here: the plugin's own bundled node_modules under the profile) triggers it — the invariant is "two physical copies", not "pnpm hoisting". Global npm install + profile-scoped node_modules is just another way to get there.

2. The convergence: this IS the 'prepare' crash. The exact Cannot read properties of undefined (reading 'prepare') + code: UNKNOWN signature appears in #2660 (two victims), #2900, #2661 (scheduler context) and #3171 (infinite loop). All of those threads were missing the trigger; your timeline evidence (works until plugin install, restored after removal) + the symbol explanation pins it. Worth posting a link to this thread from #2660 so the crash-cause thread gets its root cause.

3. On bevinkatti's points — agree, with one precision.

• Symbol.for() alone would indeed not make duplicated module instances safe (module-level state could still diverge) — correct. For this specific key the scheduler is a class-field initializer with no shared mutable state, so Symbol.for would fix the lookup, but the broader point stands: it papers over the duplicate rather than removing it.
• Host-owned capability injection is the right long-term boundary — it matches the fix direction I've been proposing: the scheduler should be reached through a host-registered capability, not through a module-scoped symbol that any second copy can shadow. Practically, that's a runtime guard at tool-calls.ts:169 (detect undefined scheduler → synthesize a clean tool/result error instead of throwing mid-loop) + a reconcile denylist arm in apps/cli/src/plugin.ts (warn/fail when a profile dependency declares a core @deepseek-ai/dsh-* package — the profile's dependency block should only ever hold out-of-tree plugins). Both are still unimplemented on rc.7 (verified: no guard at :169, no denylist in plugin.ts).
• The dangling tool/call failure path is independently real — it's the DSH Bug 反馈报告：工具执行崩溃后回合被标记为已结束，留下悬空 tool_calls，会话永久 400 卡死 #2900/A turn ending with a scheduler error leaves orphaned `tool_calls` that permanently poison the session (INVALID_REQUEST on every later message) ｜ 轮次以调度器错误结束时残留孤立 tool_calls，永久毒化会话（后续每条消息都报 INVALID_REQUEST） #2661 mechanism (family #9, balanced-but-dangling): appendToolCall commits before dispatch (tool-calls.ts:167-168), so any throw after that line (including this one) leaves an orphaned call → every later turn 400s. The runtime guard at :169 doubles as the fix for this crash's poison side: a synthetic tool/result there closes the call even when the scheduler is missing. And the durable backstop (extend interruptedTurnClosers to scan closed turns, or a serialize-time pairing check) protects all future writers.

4. One-PR shape if the channel opens (all pieces verified): tool-calls.ts:169 guard + synthetic result (closes the poison loop), reconcile denylist arm in plugin.ts (prevents the trigger), and the #2900 repair/serialize backstop. Three small, independently-testable changes; the regression test is your repro (install a plugin bundling dsh-tools → assert a clean error tool/result, not undefined.prepare).

Solid report — the before/after timeline is what makes it conclusive. This thread deserves a link from #2660.

[argszero]

Correction/addendum to my earlier comment: I stated #2660 "was missing the trigger" — that was wrong. #2660 is the canonical root-cause thread and predates yours: same duplicate-copy symbol mechanism, with runtime probe evidence (realpath comparisons DIAG-TOP/DIAG-CTOR2) and a repro on Windows/rc.6 (pnpm-hoisted copy). Your report remains valuable as the second independent confirmation — macOS/rc.7/bundled-copy trigger, extending the model from "pnpm hoisting" to "any second physical copy" — but credit for the root-cause identification belongs to #2660.

I've posted the full convergence (family lineage, fix-blueprint reconciliation incl. #2660's loader-priority idea) on #2660 — linking both threads so each carries the complete chain: trigger (duplicate copy) → crash (undefined.prepare) → poison (orphaned tool/call) → permanent 400.

[bevinkatti]

Thanks for the clarification and for tracing this back to #2660. The distinction between fixing the symbol lookup and actually eliminating duplicate runtime instances was what I was getting at with Symbol.for() vs a host-owned capability. The tool/result guard also makes sense as an independent safety net for preventing the scheduler failure from poisoning the session chain.