本轮运行失败Cannot read properties of undefined (reading 'prepare')

[vancur2021]

本轮运行失败Cannot read properties of undefined (reading 'prepare')

[vancur2021]

回退可用： git reset --hard c6c3ad9

不会退的方案：

diff --git a/apps/cli/src/profile-boot.ts b/apps/cli/src/profile-boot.ts
index ededd48a87..fd7bb8efc4 100644
--- a/apps/cli/src/profile-boot.ts
+++ b/apps/cli/src/profile-boot.ts
@@ -238,7 +238,7 @@ export interface RunProfileOptions {
   args: readonly string[]
   /** Application-owned package runtime, scoped to plugin package operations. */
   packageManager?: ProfileContext['packageManager']
-  /** Module fallback backend; defaults to runtime. Plain Node callers may override it; pkg executables always use runtime. */
+  /** Module fallback backend; defaults to link. Plain Node callers may override it; pkg executables always use runtime. */
   resolutionMode?: ProfileResolutionMode
 }

@@ -260,7 +260,7 @@ export async function runProfile(options: RunProfileOptions): Promise<{ ctx: Con
   )

   const packaged = (process as NodeJS.Process & { pkg?: unknown }).pkg !== undefined
-  const resolutionMode = packaged ? 'runtime' : options.resolutionMode ?? 'runtime'
+  const resolutionMode = packaged ? 'runtime' : options.resolutionMode ?? 'link'
   const app: { current?: Context } = {}
   let disposal: Promise<void> | undefined
   const dispose = (): Promise<void> => disposal ??= (async () => {
diff --git a/apps/cli/tests/built-bin.e2e.ts b/apps/cli/tests/built-bin.e2e.ts
index dbaf904569..781396262a 100644
--- a/apps/cli/tests/built-bin.e2e.ts
+++ b/apps/cli/tests/built-bin.e2e.ts
@@ -984,7 +984,7 @@ describe.skipIf(!existsSync(dshBin))('dsh BUILT bin (node lib/bin.js, no tsx)',
     try {
       await waitForFile(fixture.ready)
       expect(readFileSync(fixture.echo, 'utf8')).toBe('bundle-default')
-      expect(existsSync(join(fixture.home, 'profiles', 'node_modules'))).toBe(false)
+      expect(existsSync(join(fixture.home, 'profiles', 'node_modules'))).toBe(true)
       requestProfileShutdown(child, fixture)
       expect((await child).exitCode).toBe(0)
     } finally {
diff --git a/apps/cli/tests/resolved-profile-boot.spec.ts b/apps/cli/tests/resolved-profile-boot.spec.ts
index e968f91504..22a5decb84 100644
--- a/apps/cli/tests/resolved-profile-boot.spec.ts
+++ b/apps/cli/tests/resolved-profile-boot.spec.ts
@@ -91,7 +91,7 @@ describe('runProfile with an application-owned profile', () => {
   })

   it.each([
-    { selection: 'default', options: {}, mode: 'runtime' },
+    { selection: 'default', options: {}, mode: 'link' },

[limoonrise]

你回退可用了嘛，我回退不能用，好草台班子啊 🤷🏻‍♀️🤷🏻‍♀️🤷🏻‍♀️

回退的那个版本可用的，要新会话

[limoonrise]

你回退可用了嘛，我回退不能用，好草台班子啊 🤷🏻‍♀️🤷🏻‍♀️🤷🏻‍♀️

#7219，实测有用！

[Justdkd]

@Gniy7Ga 使用源码install后全新对话不调用任何tools也会失败，利用quick start install开启端口可以进行对话，但一旦想让Deepseek帮忙调用tool就会失败。我所有操作都是在install后马上进行，没有历史对话。

目前HEAD在

ddefc45 (HEAD -> master, tag: dsh-v0.1.6-alpha.2, origin/master, origin/HEAD) Merge pull request #4469 from deepseek-harness/worktree/release-dsh-0.1.6-alpha.2

[Gniy7Ga]

@Justdkd 这次补充明确了版本和全新会话条件，不能再只按旧会话残留来解释。我已把这个差别补入现有调查。还需要区分两种失败：源码入口纯文字对话失败时，以及 quick start 入口调用工具失败时，各自显示的完整错误是什么？也请贴一下这两个入口实际使用的启动命令；仅凭安装方式还不能确认是否走了构建产物入口。提供脱敏的错误文字即可。

[kingshuaishuai]

你回退可用了嘛，我回退不能用，好草台班子啊 🤷🏻‍♀️🤷🏻‍♀️🤷🏻‍♀️

回退的那个版本可用的，要新会话

我换了新对话用低版本可以了，我这里是一旦对话坏了，不管用什么方式，这个对话都不行

[MrThanlon]

我chovy, 你们给我测好了再发呀

[tangjinchun]

我搞了半天，发现是一个bug，然后看到你们都已经提了

[zhuminghuid]

今天更新完就不行了

[yemaozi1299]

node apps\cli\lib\bin.js web 目前只能先这样启动了

[AzureHalcyon]

apps/cli/src/profile-boot.ts:262

• const resolutionMode = packaged ? 'runtime' : options.resolutionMode ?? 'link'

• const resolutionMode = packaged ? 'runtime' : options.resolutionMode ?? 'runtime'
  这应该就是问题原因

[coldxiangyu163]

同源问题的修复见 #7048：根因是 profile 解析的 declaring 锚点经 pnpm 符号链接落在 node_modules 下，tsx 因此跳过 tsconfig paths，同进程出现两份 @deepseek-ai/dsh-tools（Symbol 不匹配）。

修复（4 行，锚点规范化为真实路径）+ 回归测试 + 有/无构建产物与端到端复测都在 #7048 里。修复合入前，改用构建入口启动（pnpm exec node apps/cli/lib/bin.js web）可作为临时规避。

[Gniy7Ga]

已收到。@vancur2021 @zhuminghuid 方便补充出错时的 DSH 版本号和启动命令吗？需要据此区分源码启动与其他安装方式下的同名报错。

[xiaohp]

源码方式，master 分支最新代码可复现：

git clone https://github.com/deepseek-ai/deepseek-harness.git
cd deepseek-harness
pnpm install
pnpm run build
pnpm dsh web

[yemaozi1299]

输出了一篇今天的排查过程，而且衍生出另一个问题，触发这种报错后，这个会话就废了
https://blog.csdn.net/a1299047617/article/details/165882603

[Gniy7Ga]

@yemaozi1299 想确认你说的会话无法继续：切换到构建入口后，原会话仍会失败、而新建会话可以正常使用吗？原会话此时的具体报错是什么？这有助于区分启动入口问题和失败后的会话恢复问题。

我当前的读取范围不包含这篇站外博客，尚未读到其中的排查内容；方便把与会话恢复有关的关键错误片段贴在这里吗？请先去掉密钥、账号和私人内容，不需要公开完整会话。

[Nomit8088]

@Gniy7Ga 这是我结合评论以及本机日志的复测结果,辛苦看下

1) 换构建入口（node apps/cli/lib/bin.js web）之后：新建会话正常，原会话仍然失败，而且报错变了

原会话不再报 reading 'prepare'，而是：

DeepSeek Messages tool calls need immediate results   (code: INVALID_REQUEST)

也就是说这跟启动入口无关 —— 入口问题只决定"第一次崩溃会不会发生"，原会话已经写坏的日志不会因为换入口而恢复。

2) 原会话为什么必死：崩溃点恰好落在 tool/call 已落盘、tool/result 还没写之间

该会话 turn 2 的事件序列（只列类型与序号，已去敏）：

seq 30  assistant/message   2 个 tool-call（pwsh、glob）
seq 31  tool/call           只落了第一个，且没有任何 tool/result
seq 32  step/end
seq 33  turn/end            { reason: { kind: 'error', error: { message: "Cannot read properties of undefined (reading 'prepare')", code: 'UNKNOWN' } } }

之后每一轮在发出请求前就被自己拒掉：

seq 39 / 47  assistant/attempt → finish error "DeepSeek Messages tool calls need immediate results" (INVALID_REQUEST)

对应 packages/llm/llm-deepseek/src/protocols/messages/serialize.ts:117：assistant 的 tool_use 必须紧随 tool_result，而这两条 tool call 一条结果都没有。

3) 现有恢复机制救不了它

• packages/core/agent-loop/src/tool-calls.ts:241/250：只有"用户取消（aborted）"分支会补合成结果，派发失败的分支不补，所以留下孤儿 tool/call；
• packages/core/session/src/repair.ts:82：只在"尾巴 turn 仍未闭合"时补，而这次 harness 自己用 turn/end{kind:'error'} 关掉了 turn（openTurn === null → 直接返回空）；
• packages/core/session/src/invariant.ts：step/end 只是 clear pendingCalls，turn/end 也只校验 step 是否关闭，都不校验 pending 调用是否已配对。

结论：重启 / 重新 resume / 换入口都不会修好；只能把该 turn 之前的日志截断，或给两个 callId（pwsh、glob）各补一条合成 tool/result（TOOL_OUTCOME_UNKNOWN / TOOL_NOT_STARTED）才能继续用。

4) 补充 #7048 的 A/B 证据（本机实测）

只改 apps/cli/src/profile-boot.ts 里 options.resolutionMode ?? … 那行默认值，同一个探针插件、同一次源码启动：

默认值	活的 tools 实例上的 scheduler 符号 vs 裸 import 得到的符号	结果
'runtime'（0.1.6-alpha.2 新默认）	identical: false，instance[bareSymbol] === undefined	必崩（就是本 issue 的报错）
'link'（0.1.5-rc.1 及以前默认）	identical: true	工具调用正常

同进程里还能直接量到两份模块：node --import tsx/esm 下 import.meta.resolve('@deepseek-ai/dsh-tools') → packages/core/tools/src/index.ts，而显式 import .../lib/index.js 是另一个实例（same module: false）。这与 #7048 的"锚点经 pnpm 符号链接落在 node_modules 下，tsx 因此跳过 tsconfig paths，同进程出现两份 @deepseek-ai/dsh-tools"一致。

排查内容都在上面了，不需要看站外博客；完整会话我没贴，只有上面这段去敏的事件序列。

5) 建议的修复（除 #7048 的锚点修复外，建议一并考虑）

这次真正"把会话写死"的不只是那个 TypeError，而是派发失败的善后缺了两块。建议：

1. 派发失败也要补齐结果（packages/core/agent-loop/src/tool-calls.ts）
   现在只有 aborted（238-243 行）走 appendSkippedToolCall；schedulerFailure（232-236 行）直接把错误抛出去，于是"已 tool/call、未 tool/result"的缺口留在日志里。
   建议：在重抛之前，对每个已 appendToolCall 但未 commit 的调用按模型顺序补一条合成 tool/result（沿用 TOOL_ABORTED_BEFORE_DISPATCH 那个形状，或新增 TOOL_DISPATCH_FAILED 之类的 code）。这样任何中途失败都不会再产生不可重放的日志。

2. 让这类日志在"写"的时候就暴露（packages/core/session/src/invariant.ts）
   invariant 已经在跟踪 pendingCalls，但 step/end 直接 clear、turn/end 不看它，所以这次是等到下一轮被 provider 拒才发现。
   建议：step/end（或至少 turn/end）在 pendingCalls 非空时判 invariant 失败 —— 第 1 点补上后这条应当恒成立，属于廉价保险。

3. 已经坏掉的会话需要一条恢复路径
   repair.ts 的合成关闭只能"追加在未闭合的尾巴 turn 后面"；对已经 turn/end 关掉的 turn，追回 tool/result 会破坏 turn 边界，所以不能靠追加修。
   建议二选一：

   • 加载/恢复时把它识别成 unreplayable，给出可操作诊断，并允许用户丢弃该 turn（走 session 格式的 successor generation / 截断，而不是在投影层伪造结果 —— 那会违反"model-visible ⟺ logged"）；
   • 或者显式提供一次性修复动作（把该 turn 的 assistant tool-call 段与孤儿 tool/call 一起裁掉），避免用户只能弃会话。

4. 顺带把这类跨模块符号握手做得平面无关（packages/core/tools/src/index.ts:463）
   TOOL_RUNTIME_SCHEDULER 用的是 Symbol(...)（每个模块实例一个）。即便 [修复方案] 源码启动 prepare 崩溃：profile 解析锚点未规范化导致 tsx 跳过 paths（fork 分支 + 回归测试 + 端到端验证） #7048 修好了锚点，同进程出现两份 dsh-tools 时这个握手依然会静默变成 undefined 并炸在 tool-calls.ts:170。
   建议改成 Symbol.for('@deepseek-ai/dsh-tools.scheduler')（unique symbol 的类型声明需要相应调整），或干脆不用符号、走正式的服务方法暴露给 agent-loop。这样即使解析再出偏差，也不会以"裸 TypeError + 写死会话"的形式爆出来。

[yemaozi1299]

@Nomit8088 写得很详细了，这里我附上截图

[YMofBZS]

环境：Windows 11 / Node v20 / 全局安装 npm
触发条件：升级到 rc1.6-alpha2 后，执行任何文件读取或 shell 命令。
实际结果：直接抛出 Cannot read properties of undefined (reading 'prepare')，整个工具链瘫痪。
我的经历与吐槽（这是重点）：
我原本有一个运行完美的环境，因为相信你们的更新，升级到了 rc1.6-alpha2。结果整个下午什么都没干，全耗在排查这个 prepare 报错上。
我删了 profiles 目录，清理了 npm 缓存，甚至把所有的 skill 和 MCP 全删了从头再来，依然报错！

[byqy]

遇到异常还是直接回退版本最快，自己排查解决实在太浪费时间了。

[tangjinchun]

我也是，从08:30到11:30。我才发现你们早已经提Discussions了。还是乖乖回退版本了

[wanglinsss]

功力尽失了

[WXY-YXW996]

解决方案（大概）：
packages/core/tools/src/index.ts:463

-export const TOOL_RUNTIME_SCHEDULER: unique symbol = Symbol('@deepseek-ai/dsh-tools.scheduler')
+export const TOOL_RUNTIME_SCHEDULER: unique symbol = Symbol.for('@deepseek-ai/dsh-tools.scheduler')

Symbol.for 按字符串走进程级全局注册表，因此无论模块被求值多少次，这个契约都能保持一致。它与
unique symbol 类型兼容，也与 cordis 既有的写法保持一致。

已在同一份检出上本地验证：仅改这一行并重新 pnpm run build 后，上述复现脚本的结果变为
TOOL_RUNTIME_SCHEDULER in ctx.tools? true，工具调用正常派发，
npx vitest run packages/core/agent-loop packages/core/tools 保持全绿（36 个文件 / 843 个用例）。

[LosFurina]

pnpm dsh web 会通过 tsx 启动源码。我实测这时 @deepseek-ai/dsh-tools 指向 src/index.ts；普通 Node 启动构建版时则指向 lib/index.js。两者生成的工具调度器 Symbol 不相同
从仓库根目录运行已构建的 CLI：
node .\apps\cli\lib\bin.js web

[reina4xa]

我chovy！我以为又炸插件了，紧急disable了由remove了一波，版本给我拿测好的啊

[LiuisKim]

我还以为自己插件问题，原来是有bug

[jinyu918]

中午更新完测了一下，发现咋测就报错就来看社区了，果然是测试问题，人麻了

[jinyu918]

建议直接想楼主说的回退，省心省力

[Lanuxu]

为什么切换回dsh-v0.1.6-alpha.2还是报错

[Gniy7Ga]

@Lanuxu 这个话题里也有在 0.1.6-alpha.2 上遇到错误的反馈，因此切回 alpha.2 并不能保证避开它。你现在的具体报错仍是 reading 'prepare'，还是变成了其他错误？也请贴一下实际启动命令；需要据此区分启动入口问题和原会话恢复失败。

[STARDUSTLC666]

补一个可能与上面源码启动路径不同的触发变体，供官方区分同名报错（本机探针结论，欢迎用 module 探针复核）：

环境：DSH 0.1.6-alpha.2，Windows 11；同机 0.1.5-rc.2 + 同一插件/预设正常。升级后全新会话第一个工具调用（只调 run_code）就报 Cannot read properties of undefined (reading 'prepare')。

本机核对：

• ~/.dsh 下没有第二份 @deepseek-ai/dsh-tools（不是 profile 多拷贝那条）；
• 两份 TOOL_RUNTIME_SCHEDULER 都来自 lib/，不是 tsx 的 src/lib 混载：一份来自 lib/index.js，另一份来自 lib/types/*.js 这套构建产物；
• 而 @deepseek-ai/dsh-tools 自己的 package.json exports 把子路径指向了第二套构建：
  • . → lib/index.js
  • ./types → lib/types/types.js
  • ./presentation → lib/types/presentation.js
• lib/index.js 与 lib/types/index.js 各自定义了一份 Symbol('@deepseek-ai/dsh-tools.scheduler')，所以单单一份官方安装就可能出现两个模块实例、两个不相等的 symbol。
• 触发预设是 PTC（dsh-minimal-ptc；它只做 tool-presentation: mode: ptc，把它按官方 0.1.6 PTC 预设对齐后仍复现）。

本地验证：把 packages/core/tools/src/index.ts:463 的 Symbol(...) 改成 Symbol.for('@deepseek-ai/dsh-tools.scheduler')（和上面 WXY-YXW996 同一条）后，工具调用恢复；但这只解决"跨实例 key 相同"，exports 路由到两套构建产物本身仍在。#7011 汇总的四项（源码/产物单一模块平面、Symbol.for、同包多 realpath 检测、写 tool/call 前校验 scheduler）应该一起做。

区分意义：如果只修 tsx/src-lib，或只做 profile 去重，这条"官方包自身 exports 双构建"路径可能仍会触发。相关：#7011、#6529、#7048、#7062。

English TL;DR: On my machine the two TOOL_RUNTIME_SCHEDULER instances are both under lib/ — lib/index.js vs the second build tree lib/types/*.js, which the package's own exports map routes ./types and ./presentation into. So a single clean install of @deepseek-ai/dsh-tools@0.1.6-alpha.2 can already yield two module instances; no tsx source launch, profile duplicate, or HMR needed on this path. Local Symbol.for(...) fixes the lookup; the dual-build/exports issue remains.

[Gniy7Ga]

@STARDUSTLC666 这个区别很重要：你报告的是同一包内两套 lib 构建产物，而不是源码与产物混载。我核对到包的 exports 确实有你指出的路由，已把这条变体补进现有调查，单独核查纯产物启动和 PTC 的场景；目前还不能确认运行时双实例的具体形成过程，也不会把源码入口恢复或本地 Symbol.for 绕过当作这条路径已修复。

[doonygit]

这个问题，上周一更新完，就有这个问题了，卸载了重装，到今天早上试了依然不行，要疯了，大侠们，能否测试好了再发版啊，都想删掉了。。。

[Gniy7Ga]

@doonygit 更新后一直无法使用、重装也没恢复，确实很影响使用。截图里是读取文件时出现 prepare 错误，你补充的本地构建版本也看到了。还想确认你用的操作系统，以及启动方式（桌面客户端，还是终端命令；若是命令请贴启动那一行）。这些信息用于区分源码启动和构建产物入口，避免把不同路径的同名报错混在一起。

[doonygit]

操作系统：windows10，pnpm dsh web启动。并且已经试过，把c盘下的.dsh文件夹，删除了重新编译、安装，依然报这个错。

[Gniy7Ga]

@doonygit 这次补充确认了是 Windows 10 下用 pnpm dsh web 启动，和现有的源码入口工具调用失败调查相符。我已把你的版本、截图及重新编译安装仍失败的情况补入同一调查，交由团队一起核查。目前还没有可确认解决这一场景的发布版本，不建议继续删除 .dsh 数据目录来尝试。

[doonygit]

把前端工程师绑了祭天，顺带测试工程师也得搭个双腿，不然不足于平民愤

[World-sudo]

这个问题，上周一更新完，就有这个问题了，卸载了重装，到今天早上试了依然不行，要疯了，大侠们，能否测试好了再发版啊，都想删掉了。。。

回退0.1.5可以 但是好像会话就不可用了

[rays2004]

我问deepseek，它给出的解决方案是 一个命令 ‘New-Item -ItemType Junction -Path "C:\Users\Administrator.dsh\profiles\web\node_modules@deepseek-ai\dsh-tools" -Target "E:\workspace\deepseek-harness\packages\core\tools" ‘，我运行后重新编译，就好了

[Luminous-xh]

我chovy，你们测产品给我测好了再拿给我啊

[adisby]

tmd，兴冲冲回家，被当头一棒

[liucf1224-del]

都这么久了 还不发版更新修复一下吗

[lindorx]

diff --git a/packages/core/tools/src/index.ts b/packages/core/tools/src/index.ts
index 6be7be61e2..b5a718cdda 100644
--- a/packages/core/tools/src/index.ts
+++ b/packages/core/tools/src/index.ts
@@ -460,7 +460,7 @@ export interface ToolRuntimeScheduler {

• Scheduler entry point omitted from the generated named service API.
• @internal
  */
  -export const TOOL_RUNTIME_SCHEDULER: unique symbol = Symbol('@deepseek-ai/dsh-tools.scheduler')
  +export const TOOL_RUNTIME_SCHEDULER: unique symbol = Symbol.for('@deepseek-ai/dsh-tools.scheduler')

/** Canonical error code for cancellation after a tool body was invoked. */
export const TOOL_ABORTED = 'ABORTED'

[Gniy7Ga]

我刚核对了公开发布，目前最新仍是 dsh-v0.1.6-alpha.2，尚未查到包含这项工具调用修复的可用新版，也没有可确认的发版时间。帖子里的 link／Symbol 修改是本地绕过验证，不能视为正式发版。确认修复进入可用版本后，会在这里回告。

[liucf1224-del]

diff --git a/packages/core/tools/src/index.ts b/packages/core/tools/src/index.ts index 6be7be61e2..b5a718cdda 100644 --- a/packages/core/tools/src/index.ts +++ b/packages/core/tools/src/index.ts @@ -460,7 +460,7 @@ export interface ToolRuntimeScheduler {

• Scheduler entry point omitted from the generated named service API.
• @internal
  */
  -export const TOOL_RUNTIME_SCHEDULER: unique symbol = Symbol('@deepseek-ai/dsh-tools.scheduler')
  +export const TOOL_RUNTIME_SCHEDULER: unique symbol = Symbol.for('@deepseek-ai/dsh-tools.scheduler')

/** Canonical error code for cancellation after a tool body was invoked. */ export const TOOL_ABORTED = 'ABORTED'

确实可以解决现在的这个bug

[charonwang]

补充一份实测结果：Windows 11、Node 24.16.0、pnpm 11.7.0，使用 pnpm dsh web（源码入口）在 ddefc45fbc 上稳定复现 Cannot read properties of undefined (reading 'prepare')。执行 pnpm run clean 和构建后仍会复现。

将 TOOL_RUNTIME_SCHEDULER 从 Symbol(...) 改为 Symbol.for('@deepseek-ai/dsh-tools.scheduler')，重新构建并重启后工具调用恢复；Source/Lib 两份模块的 scheduler key 也变为一致。agent-loop 工具测试和无密钥 Source/Lib smoke 均通过。

这进一步确认是同一进程加载了不同模块实例导致 symbol 不一致。原失败会话因已写入 tool/call 但没有 tool/result，仍不能可靠恢复，需要新建会话。未附 session 文件或任何凭据。

[World-sudo]

修复：#7079
希望会有帮助

[Bleachtred]

四天了 还没修复 干什么吃的

[Alsctiho]

你们的回归测试呢，吃白饭的大肥鱼？气死我了

[RupertCui]

赶紧修复吧，已经三四天没用dsh干活了，问啥都挂
Cannot read properties of undefined (reading 'prepare')

[firemakergk]

果然如果遇到了过于奇怪的情况就需要到社区看看

[stranlc]

HANDOVER-to-3080.md
让另一个旧版本的harness修这个更新到0.1.6-alpha.2版本的harness，成功修复（但有一些小代价），这文件是我让它整理的“修复经验”

[tianyicui]

感谢汇报bug，会在即将发布的下一个版本修复。

[liruilong9999]

啥时候啊

[smartyhero]

它一上来就失败了，关键它把我账户余额的1.4都花完了啊

[Gniy7Ga]

@smartyhero 截图能确认先出现 prepare 错误，随后继续同一会话又报 tool calls need immediate results，这条会话目前不宜继续反复重试。账单显示两次请求、731,275 tokens、¥1.45，但仅凭这两张图还不能确认费用分别对应哪一轮，也不能据此判断异常扣费。

麻烦补充当时的 DSH 版本和启动方式，以及这两笔请求的时间、输入/输出 token 明细，便于核对失败与计费发生的先后；请遮掉 API Key、账号等信息，不用公开完整会话。

[VarianWrynn666]

补充一份可无密钥复现、带模块解析探针的证据链（Windows 11 / Node v24.18.0 / pnpm 11.7.0 / tsx 4.22.4 / 快照 2026-09-17 / 0.1.6-alpha.2）：

现象：pnpm dsh（即 node --import tsx/esm apps/cli/src/bin.ts）下，使用随附 profile、未安装任何第三方插件，首个工具调用即报 UNKNOWN: Cannot read properties of undefined (reading 'prepare')；会话日志为 assistant/message → tool/call → step/end → turn/end(kind=error)，没有 tool/result，工具未派发。

机制（同一进程出现两份 @deepseek-ai/dsh-tools）：用 node:module 的 registerHooks 记录 (specifier, import 方, 解析结果)，可见同一进程里：

@deepseek-ai/dsh-tools <= apps/cli/node_modules/@deepseek-ai/dsh-base/package.json => packages/core/tools/lib/index.js
@deepseek-ai/dsh-tools <= packages/core/agent-loop/lib/index.js => packages/core/tools/src/index.ts

即：插件入口经安装/bundle manifest 锚点由 Node 内部解析落到 lib（构建产物）；而 lib 文件内部的裸导入被 tsx 按 tsconfig base 的 paths 投影回 src。TOOL_RUNTIME_SCHEDULER 是模块局部 Symbol(...)，两份副本取值不相等，ctx.tools 上查表得 undefined，读 .prepare 即崩。这与 #7048 中 declaring 锚点经 node_modules 符号链接导致 tsx 跳过 paths 的分析一致。

无密钥复现（不需要 DEEPSEEK_API_KEY）：

1. pnpm install && pnpm run build

2. 启动仓库自带 mock LLM：pnpm run mock:llm --port 8017 --api-key mock-key --sequence tool_call_success,success --repeat-last --tool-name pwsh；并加一个 overlay 把 llm-deepseek 的协议改成 chat-completions（mock 只应答 chat-completions）：

   - id: llm-deepseek
     config:
       protocol: chat-completions

3. DSH_HOME=<临时目录> DEEPSEEK_BASE_URL=http://127.0.0.1:8017/v1 DEEPSEEK_API_KEY=mock-key node --import tsx/esm apps/cli/src/bin.ts --profile headless --patch <overlay> probe → 首个工具调用即报上述错误。

4. A/B 对照：同一场景改用 node apps/cli/lib/bin.js --profile headless --patch <overlay> probe → 工具正常执行，turn/end 记录为 kind=completed。

结论：README 的源码启动（pnpm dsh web）在没有任何额外插件时就会命中该问题；修复合入前可用 node apps/cli/lib/bin.js web 稳定规避；Symbol.for 一行修复对任意副本数都成立，能消除这类身份敏感键的跨副本失效。需要的话我可以补充探针脚本与解码后的会话日志。