源码启动（pnpm dsh）在已构建 lib/ 的树上所有工具调用失败：Cannot read properties of undefined (reading 'prepare')

[kendu76]

Summary

升级后在源码启动（node --import tsx/esm apps/cli/src/bin.ts，即 pnpm dsh）且仓库存在已构建 lib/ 产物的状态下，每一轮 turn 的第一个工具调用（bash、glob 等任意工具）都会失败，整个 turn 以 UNKNOWN 结束：

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

受影响场景：任意已有工作区中，agent 的所有工具调用全部失败，任务无法推进。会话日志里每个 turn 都是 tool/call 之后直接 turn/end {kind:'error', code:'UNKNOWN'}。

Reproduction

无 key 即可复现（官方 recorded-session 回放）：

pnpm run build
pnpm run test:snapshot -t bash-tool-turn
# → FAIL: dsh: UNKNOWN: Cannot read properties of undefined (reading 'prepare')

而 CI 的跑法（单一 lib 平面）通过：

DSH_EXAMPLE_MODE=lib pnpm run test:snapshot -t bash-tool-turn
# → PASS

线上场景：pnpm dsh web 启动物化在 ~/.dsh/profiles/web 的 live profile 后，任意会话的第一个工具调用即崩。

Current behavior

• 源码启动 + 已构建 lib/：所有工具调用失败（上述 TypeError），turn 以 {kind:'error', code:'UNKNOWN'} 结束。
• pnpm run clean 删除 lib/ 后源码启动：启动期失败，约 47 个插件 failed to import（"required plugins did not activate"）——仓库外配置条目只能经 package exports 解析到 lib/，没有 lib/ 就 loudly 失败。

即源码启动对配置树在仓库外的 profile（任何 live profile）两种状态都无法工作。

Expected behavior

按 .agents/notes/implemented/architecture/2026-07-29-dsh-source-launch-tsx-esm.md 的契约（"tsx applies the paths map unconditionally"），源码启动应把所有 cordis.yml 裸插件解析到与仓库内模块相同的单一平面（src/），工具调用正常工作。

Root cause

1. 源码启动时，仓库内 import 经 tsx（tsconfig paths）解析到 src/；
2. cordis loader 对 cordis.yml 裸插件名走 ctx.loader.internal.import(name, ctx.baseUrl)（vendor/loader/src/config/tree.ts:122），即 Node 内部 ESM loader（经 node-addon-require-builtin 可达，vendor/loader/src/index.ts:73），解析父路径是配置文件所在目录；
3. 配置树在仓库外（live profile 物化到 ~/.dsh/profiles/<name>）时，该父路径没有 tsconfig 生效，解析退回 package exports → lib/；
4. 于是 @deepseek-ai/dsh-tools 被加载两份。TOOL_RUNTIME_SCHEDULER 是 Symbol()（packages/core/tools/src/index.ts:463），按模块实例唯一：tools 服务由一份实例提供，而 agent-loop（整体来自 lib/）用另一份实例的 Symbol 读取 ctx.tools[TOOL_RUNTIME_SCHEDULER] 得到 undefined，第一个工具调用在 packages/core/agent-loop/src/tool-calls.ts:170 抛出 undefined.prepare() → turn 捕获后展平为 UNKNOWN（packages/core/agent-loop/src/agent.ts）。

模块加载探针实测（临时在模块顶部插桩）：

[dbg-src-loaded] …/packages/core/tools/src/index.ts          ← 经 loader，paths 平面
[dbg-lib-loaded] …/packages/core/tools/lib/index.js          ← 经 loader，exports 平面
[dbg-lib-loaded] …/packages/core/agent-loop/lib/index.js     ← 经 loader，exports 平面

（agent-loop 的 src 副本从未被加载，所以 turn 的 UNKNOWN 来自 lib 副本的 catch。）

为什么 CI 没拦住

snapshot 门禁在 CI 中是 DSH_EXAMPLE_MODE=lib 且先 pnpm run build（scripts/run-gates.ts 的 snapshotGate）——单一 lib 平面，天然一致。src 启动契约冒烟（apps/cli/tests/source-launch.compat.spec.ts）只断言 TTY 拒绝退出码，不做完整插件启动。"源码启动 × 已构建 lib/"这个组合在 CI 中没有覆盖。

修复方向建议

让源码启动下裸插件解析保持单平面。例如：source launch 下不启用 internal loader（ModuleLoader.fromInternal()），tree.ts 退回普通 import(name)——tsx hook 会把解析统一到 src/；或让 loader 的解析按 tsconfig paths 映射。

Workaround（修复前）

pnpm run build 后改用构建入口启动（单一 lib 平面，已验证 lib 模式 snapshot 通过）：

node apps/cli/lib/bin.js web --no-open

注意 restart-dsh 插件会按当前进程原始 argv 重放启动命令，从源码入口切到 lib 入口时不要用它的重启按钮。

Environment

• macOS darwin 25.6.0 arm64，Node v24.13.1
• master @ ddefc45fbc（release dsh 0.1.6-alpha.2），工作树干净
• live profile：~/.dsh/profiles/web（含 marketplace 插件物化树）

补充说明

internal.import 这条解析路径自初始 vendoring（72688a3888）就存在，不是近期提交引入的回归；"升级 + 重新构建"只是第一次同时凑齐了三个条件（源码启动 × 仓库外 profile 配置树 × 已构建 lib/）。

[kendu76]

补充定位（根因已进一步收窄，并验证了修复方向）

触发本 bug 的是同一升级窗口（0d1f50007f..ddefc45fbc）合入的 resolution mode 特性（9ddef327a4 feat: resolution mode link to runtime）与 tsx 源码启动的hook 遮蔽：

1. runProfile 的默认模式是 'runtime'（apps/cli/src/profile-boot.ts:263），该模式调用 createProfileResolutionGeneration（即 healProfilesModuleFallback({materialize:false})）——不再物化磁盘链接表。这就是链接表停在旧版本、新包（@deepseek-ai/dsh-plugin-manager、@deepseek-ai/dsh-hmr）没有链接的原因。
2. runtime 模式同时安装内存路由（PluginPackages → installProfileResolution，behavior enforce），本意是让 bare 插件解析全部走 generation 表、摆脱磁盘链接新鲜度问题。但在源码启动下 tsx 的 resolve hook 先于 Node 默认解析器接管了所有 bare 解析：
   • 链接表里有的包：tsx 的 nextResolve 成功 → exports → lib（碰巧与 generation 一致，正常）；
   • 链接表里没有的新包：tsx 的 nextResolve 失败 → tsx 回退 tsconfig paths → src（绕过了路由表，静默双平面 → 本 bug）。

实测证据（给 loader tree.ts import 插桩捕获）：

• 默认 runtime 模式：bash-tool-turn 复现 Cannot read properties of undefined (reading 'prepare')。
• 临时改默认为 'dual'：启动期 47 个插件 profile resolution mismatch for "..." : disk resolved .../src/index.ts, generation resolved .../lib/index.js —— verify 校验器证实了"实际解析走 src、generation 要 lib"的遮蔽矛盾（dual 在 tsx 下同样不可用，但把矛盾变成了 loud failure）。
• 临时改默认为 'link'：bash-tool-turn 通过（恢复每次启动物化链接表 + 纯 Node 解析，全部落 lib 单平面，等同升级前的行为）。

修复方向建议（按彻底程度）：

1. 最小修复：源码（非 packaged）启动的默认 resolutionMode 从 'runtime' 改为 'link'（一行，已验证通过）。代价是源码启动下放弃新路由能力。
2. 治本：让 PluginPackages 的路由以 module.register 自定义 hook 形式安装（Node 的 resolve hooks 按 LIFO 执行，后注册者先运行，可抢在 tsx 之前按 generation 表路由插件包解析），使 runtime 模式在源码启动下真正生效；dual/verify 则可作为防回归闸门保留。
3. 无论哪种，都建议给 source-launch 补一个"完整插件启动"的冒烟门禁（现有 source-launch.compat.spec.ts 只断言 TTY 拒绝），否则这类组合回归会继续漏过 CI。

[fabrithedev]

I've had the same problem today and i can confirm that node apps/cli/lib/bin.js web --no-open works as workaround.

[fatihtoprakk]

here is my problem too : #7086

[World-sudo]

u can also pay attention to mine #7079

[dsh-community-assistant[bot]]

已收到这条反馈。