[Bug] Since dsh-v0.1.6-alpha.2 every tool call fails under pnpm dsh source launch: Cannot read properties of undefined (reading 'prepare')

[Iseapisu]

Summary

On a clean checkout of master (ddefc45fbc, release dsh-v0.1.6-alpha.2), any pnpm dsh --profile headless "<task>" that triggers a tool call aborts with:

dsh: UNKNOWN: Cannot read properties of undefined (reading 'prepare')

Introduced by PR #4471 (9ddef327a4, "feat: resolution mode link to runtime"), which changed the plain-Node source-launch default resolutionMode from 'link' to 'runtime'.

Environment

• Windows 11 (10.0.26200), Node v24.16.0, pnpm 11.7.0
• Source launch (pnpm dsh → node --import tsx/esm apps/cli/src/bin.ts)
• master ddefc45fbc, real DEEPSEEK_API_KEY

Repro (deterministic)

pnpm dsh --profile headless "Use the shell tool to run 'echo hello' and report its output."

The model emits a tool call, tool/call is appended to the session log, then the turn ends with the error above and exit code 1. Any task that triggers a tool call fails; tasks without tool calls complete normally.

Root cause

Under the tsx source launch, tsconfig paths project workspace bare imports to src/. The runtime profile resolver routes plugin imports through the declaring package manifest (entry.declarer, e.g. apps/cli/node_modules/@deepseek-ai/dsh-base/package.json); resolution from that parent follows package exports into built lib/, bypassing tsx's paths projection. The same workspace package then loads twice from different planes in one process (verified with module-evaluation probes: @deepseek-ai/dsh-tools and @deepseek-ai/dsh-agent load from both src and lib; @deepseek-ai/dsh-headless only src; @deepseek-ai/dsh-agent-loop only lib).

TOOL_RUNTIME_SCHEDULER is a Symbol(...) (packages/core/tools/src/index.ts:463), so the two dsh-tools copies hold distinct symbol identities. Tool dispatch looks the scheduler up by symbol — ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(...) (packages/core/agent-loop/src/tool-calls.ts:170) — and when the registry instance and the lookup come from different copies, the lookup is undefined and every tool call crashes.

Verified fix (one line)

Restore the 'link' default for plain Node launches in apps/cli/src/profile-boot.ts:

-  const resolutionMode = packaged ? 'runtime' : options.resolutionMode ?? 'runtime'
+  const resolutionMode = packaged ? 'runtime' : options.resolutionMode ?? 'link'

After this change tool calls work again end to end (shell + read verified in one session). Packaged executables and the Electron Host still force runtime explicitly, so they are unaffected. Longer term, runtime routing would need to honor tsconfig paths (or otherwise keep one module plane) before it can be the source-launch default; a keyless source-launch e2e that performs at least one real tool call would have caught this regression.

中文摘要

0.1.6-alpha.2 起，源码启动的 dsh 一调用工具就报 UNKNOWN: Cannot read properties of undefined (reading 'prepare') 并退出。根因是 #4471 把普通启动的默认解析模式从 link 改为 runtime：runtime 路由以声明方 manifest 为父上下文重新解析插件 import，绕开了 tsx 的 tsconfig paths，同一个工作区包被同时从 src 和 lib 加载两份；TOOL_RUNTIME_SCHEDULER 是 Symbol，两份副本符号身份不一致，agent-loop 派发工具时取到 undefined。把 apps/cli/src/profile-boot.ts 的默认值改回 'link' 即恢复（打包产物与 Electron Host 强制 runtime 的路径不受影响，已端到端验证）。

[wzhejunqiu]

实测有效！

[Altermoe]

Same issue here. The fix worked for me.

[JasonChen-Uki]

Confirmed, works on Windows native!

[vancur2021]

@Gniy7Ga

[Gniy7Ga]

感谢提供复现步骤和模块加载对照。你报告的 alpha.2 源码启动后工具调用报 prepare 错误，已与现有同问题调查合并记录；另一个用户的同问题验证也已保留。文中的 link 改动是本地绕过验证，目前还不能作为已发布修复。后续会在这里回告包含修复的可用版本。

[vancur2021]

辛苦了！