[0.1.6-alpha.2] BUG: every tool call fails with "Cannot read properties of undefined (reading 'prepare')"

[BluzeOcean]

Summary

Every tool call on a freshly-built 0.1.6-alpha.2 checkout (ddefc45fbc) fails at the dispatch stage with:

This turn failed: Cannot read properties of undefined (reading 'prepare') — UNKNOWN

The model itself responds fine; the failure is in the host-side tool-execution layer immediately after the model emits the tool call.

Reproduction

pnpm install
pnpm run build
pnpm dsh web

Then in the GUI send any prompt that triggers a built-in tool, e.g. "list the files in this folder". The model generates text, suggests a tool call (e.g. Pwsh · List files in the working directory), and the turn fails before any tool body runs.

Confirmed on a completely fresh tree (full delete of repo + ~/.dsh/, git checkout HEAD -- ., fresh pnpm install, fresh pnpm run build, new DeepSeek API key).

Affected version

0.1.6-alpha.2 (ddefc45fbc). 0.1.5-rc.2 works. The regression appears in one of these three commits between 0.1.5-rc.2 and 0.1.6-alpha.2:

• 8dfc6fe1ec Merge PR DSH｜DeepSeek Harness Mobile｜用 Kuikly 跨端框架做的 Android 原生 DSH 客户端 #4471 worktree-resolutionmode
• e68f5d5aba fix: test
• d9a55c7c0d fix: revert desktop

The first one touches resolutionMode plumbing in apps/desktop-host/src/index.ts:21 and packages/boot/app-boot/src/profile-boot.ts — most plausible culprit.

Root cause (confirmed via runtime diagnostic)

Failure site: packages/core/agent-loop/src/tool-calls.ts:170

const prepared = await ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(call.exec)

ctx.tools[TOOL_RUNTIME_SCHEDULER] is undefined even though the ToolRuntime instance owns a property whose key is a Symbol with the exact same description Symbol("@deepseek-ai/dsh-tools.scheduler").

Diagnostic added to the failing line printed, at runtime:

=== DSH-DIAG: ctx.tools diagnostic ===
ctx.tools type: object is undefined: false
ctx.tools ctor name: ToolRuntime
ctx.tools own names: ["ctx","name","deferredContexts","concludingExecutions","cancellationStates","contentFinalizers","layers","defaultMode","maxParallelSubCalls","ptcTransport","canonicalResults"]
ctx.tools own symbols: ["Symbol(cordis.tracker)","Symbol(@deepseek-ai/dsh-tools.scheduler)"]
imported symbol id: Symbol(@deepseek-ai/dsh-tools.scheduler)
object has matching string desc: true
matching symbol === imported: false
ctx.tools[imported symbol] type: undefined is undefined: true
=== END DSH-DIAG ===

Symbol("foo") !== Symbol("foo") in JavaScript — the property key and the imported symbol have matching descriptions but are different instances. This means @deepseek-ai/dsh-tools is being loaded twice in the same process: once by cordis-plugin-loader (at vendor/loader/) to instantiate ToolRuntime, and once by agent-loop's ESM import. Both loaders resolve the package to the same physical file via pnpm symlinks, but Node's module cache keys on the resolved URL — if the two paths produce different URLs (e.g. one walks up vendor/loader/node_modules/, one walks packages/core/agent-loop/node_modules/@deepseek-ai/dsh-tools symlink), they get separate module instances and therefore separate Symbol instances.

The Symbol TOOL_RUNTIME_SCHEDULER is defined exactly once across the entire lib/ tree — packages/core/tools/lib/index.js:2526 — so a duplicate definition is not the cause.

Suggested fix

Ensure the cordis-plugin-loader and the workspace packages (agent-loop in particular) resolve @deepseek-ai/dsh-tools to the same module URL at runtime, so Node shares the module instance and therefore the Symbol instance. Candidates:

• Build ordering: ensure tools's lib/ is built before any consumer that imports its Symbols.
• Loader resolution: have cordis-plugin-loader resolve plugin names from the same node_modules root as the consumers.
• Module resolution: add "type": "module" consistency, or use Node's --experimental-vm-modules / explicit Symbol.for(...) / shared module instances.

Workaround

Pin to 0.1.5-rc.2 until upstream fixes this. Boots and dispatches tool calls correctly.

[argszero]

Same mechanism as #7107, #7108 and #7117 — your repro is the most complete of the four, so I will keep this to the parts that matter.

Root cause is one line. apps/cli/src/profile-boot.ts:263 at HEAD reads … options.resolutionMode ?? 'runtime'; commit 9ddef327a4 ("feat: resolution mode link to runtime", released only in dsh-v0.1.6-alpha.2) changed that ?? 'link' into ?? 'runtime'. Source launch therefore boots profile rows through the runtime resolution generation, while agent-loop's static import of @deepseek-ai/dsh-tools was linked natively before the ESM bootstrap ran — so the two planes resolve the package to different URLs and its module-level Symbol('@deepseek-ai/dsh-tools.scheduler') (packages/core/tools/src/index.ts:463) is evaluated twice. packages/core/agent-loop/src/tool-calls.ts:170 then reads ctx.tools[TOOL_RUNTIME_SCHEDULER] with the wrong key, gets undefined, and throws on .prepare before any tool body runs — which is why no tool/result appears and every later request in the session fails with INVALID_REQUEST.

The same commit also flipped apps/desktop-host/src/index.ts:21 to 'runtime', and 39 minutes later the same author reverted just that half in d9a55c7c0d ("fix: revert desktop"), restoring the conditional. Both commits ship in dsh-v0.1.6-alpha.2, so the desktop carrier already defaults to link again while the CLI carrier is still flipped.

Details, the Symbol.for sufficiency check, and the one thing that fix does not restore: #7117.