Source launch crashes on every tool call: Cannot read properties of undefined (reading 'prepare')

[msafin]

Summary

Running the CLI from source (pnpm dsh web, pnpm dsh --profile headless "…") crashes on every tool call:

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

This reproduces deterministically on a fresh headless session, independent of any existing session data:

pnpm dsh --profile headless "use the bash tool to run 'pwd' and reply with its output"
# dsh: UNKNOWN: Cannot read properties of undefined (reading 'prepare')

Regression

9ddef327a4 (feat: resolution mode link to runtime) changed the source-launch default resolution mode from link to runtime:

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

Root cause

The crash point is the agent-loop scheduler lookup:

// packages/core/agent-loop/src/tool-calls.ts:170
const prepared = await ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(call.exec)

TOOL_RUNTIME_SCHEDULER is a module-local Symbol (packages/core/tools/src/index.ts:463), compared by reference. ctx.tools[TOOL_RUNTIME_SCHEDULER] is undefined because the process ends up with two module instances of @deepseek-ai/dsh-tools — the src/ face and the lib/ face — whose symbols are unequal.

In runtime mode, createProfileResolutionGeneration + installProfileResolution patch Node's internal ESM/CJS resolvers to route bare specifiers whose parent lives inside the profile scope to the resolved installation generation. Plugin rows therefore resolve to the built lib/index.js entries (via package.json exports):

[probe] @deepseek-ai/dsh-tools     -> packages/core/tools/lib/index.js
[probe] @deepseek-ai/dsh-agent-loop -> packages/core/agent-loop/lib/index.js

But the bare imports inside those same lib files are not profile-scoped parents, so they bypass the router and fall through to tsx, which applies tsconfig paths and remaps them back to src/. The result is a split graph in one process, confirmed empirically:

// from a file inside packages/core/agent-loop/lib/:
import { TOOL_RUNTIME_SCHEDULER } from '@deepseek-ai/dsh-tools'      // -> src face
const lib = await import('.../packages/core/tools/lib/index.js')     // -> lib face
lib.TOOL_RUNTIME_SCHEDULER === TOOL_RUNTIME_SCHEDULER               // false

ctx.tools is the lib-face ToolRuntime (mounted by the row), while the loop reads it with the src-face symbol → undefined → crash.

runtime mode was built for packaged executables (no tsx, no tsconfig paths), where lib-internal imports stay on the lib face. Under a tsx source launch it is not self-consistent.

Additional failure mode (cascade)

Because the turn errors after tool/call is recorded but before tool/result (tool-calls.ts appends the call before the scheduler prepare), the session log is left with a dangling tool call. Every subsequent turn replays it and is rejected by the serializer with INVALID_REQUEST: DeepSeek Messages tool calls need immediate results (packages/llm/llm-deepseek/src/protocols/messages/serialize.ts:117), permanently bricking the session.

Suggested fix

Either:

1. Keep link as the default for source launches (restore the pre-9ddef327a4 behavior), since runtime is only correct for packaged runtimes; or
2. Make runtime mode self-consistent by also resolving bare imports whose parent is a workspace lib file onto the lib face (i.e. prevent tsx paths remapping of built output), so there is only ever one face.

Independently, consider hardening the loop against a mid-tool-call crash so a failed turn cannot leave a dangling tool/call that bricks the session (e.g. synthesize an error tool/result for started-but-unresolved calls, consistent with the existing abort path in appendSkippedToolCall).

[dmbhatti]

Confirmed on Linux (WSL2 Ubuntu 22.04, Node v22.23.2, ddefc45 / 0.1.6-alpha.2): same stack at tool-calls.ts:170, same two-face split — instrumenting the live ctx.tools shows a scheduler symbol with the right description present, but !== the src-face TOOL_RUNTIME_SCHEDULER.

One more workaround worth having alongside the Symbol.for patch in 7265: launch the built CLI entry directly, with no tsx in the process at all —

node apps/cli/lib/bin.js web            # or: --profile headless '<task>'

Everything then stays on the lib face (single module plane), and tool calls execute normally. Verified end-to-end with the bash tool returning its output. Note for WSL users: the host also needs a sandbox backend (e.g. apt install bubblewrap) or tool exec is refused with "no sandbox backend is usable" — unrelated to this bug but it masks the fix.

[husanr]

One more data point — macOS this time, and on the fix side rather than the diagnosis side.

Environment: macOS 14.0 (arm64), Node v22.19.0, pnpm 11.7.0, ddefc45fbc / 0.1.6-alpha.2, documented source-launch path (pnpm run build → pnpm dsh …).

The split reproduces straight from the source-launch vector, no instrumentation — just two imports in one process:

$ node --import tsx/esm probe.mjs
bare specifier resolves to : …/packages/core/tools/src/index.ts
relative lib specifier     : …/packages/core/tools/lib/index.js
same module instance       : false
ToolRuntime class identical: false
Symbol identity identical  : false
lookup with bare-plane key : undefined      # the crash site, reproduced in isolation

Then I reverted only the CLI default at apps/cli/src/profile-boot.ts:263 — i.e. the half of 9ddef327a4 that d9a55c7c0d did not revert:

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

$ pnpm dsh --profile headless "run pwd with the bash tool and reply with just the path"
/Users/…/deepseek-harness          # exit 0, tool executed

That same command died with UNKNOWN: Cannot read properties of undefined (reading 'prepare') immediately before the change, and that one-line revert is the only difference. So the link default appears to be the load-bearing part here — the symbol-identity split looks like the symptom, not the thing to patch. Given the desktop half already got this exact revert in d9a55c7c0d, reverting the CLI half restores symmetry.

Caveat: verified on macOS only. Windows has the separate source-launch failure in #7320, which I did not test.

[Bleachtred]

都4天了 还没修 拉

[leen1109]

dsh-v0.1.6-alpha.1 is ok. back version.

[dylkyc]

好像这个是解决方法
#7011

[secanter]

我也是这个问题！[Bug] v0.1.6-alpha.2 本地构建后按文档用 tsx 启动（pnpm run dsh web），任何工具调用都会崩溃并污染会话

Summary

按官方开发文档从源码启动 Web（先 pnpm run build，再 pnpm dsh web）后，新建会话里只要模型调用工具，本轮就会失败：
Cannot read properties of undefined (reading 'prepare')。
之后同一会话的每一轮都会失败：DeepSeek Messages tool calls need immediate results，会话不可恢复。

Environment

• dsh: dsh-v0.1.6-alpha.2（commit ddefc45），源码 checkout 启动
• 启动命令：pnpm run dsh web（= node --import tsx/esm apps/cli/src/bin.ts web），此前已执行 pnpm run build
• OS: Windows 10 22H2 (10.0.19045)
• Node: v24.16.0 / pnpm: 12.5.1 / PowerShell 5.1
• 模型与协议：deepseek-official + deepseek-flash，Messages 协议
• 是否使用第三方插件：是（profile web 里装了 2 个本地 link: 插件），但把插件全部停用后问题依旧

Reproduction

1. pnpm install
2. pnpm run build
3. pnpm run dsh web
4. 新建会话，发一句会触发工具调用的指令（例如“列出当前目录的文件”）
5. 观察本轮报错；再向同一会话发送任意一条消息

Current behavior

• 第 1 轮：turn/end 返回
  {"kind":"error","error":{"message":"Cannot read properties of undefined (reading 'prepare')","code":"UNKNOWN"}}；
  会话日志里只写入了一个 tool/call，没有对应的 tool/result（packages/core/agent-loop/src/tool-calls.ts 的文件头注释说明：终态调度器失败会保留已记录的 tool/call 而不伪造结果）。
• 第 2 轮起（同一会话）：请求阶段即失败，DeepSeek Messages tool calls need immediate results
  （packages/llm/llm-deepseek/src/protocols/messages/serialize.ts:117：历史里 assistant 的 tool_use 没有紧随的 tool_result）。

Expected behavior

工具正常执行；即便工具调度失败，也不应把会话变成无法继续的状态（例如写入一条合成的错误 tool/result，或明确提示需要新开会话）。

Root cause（已定位并在本机复现）

同一进程里 @deepseek-ai/dsh-* 包被加载了两份——组合条目走构建产物 lib/，而它们的依赖走源码 src/：

1. 组合条目由 cordis Loader 通过 loader.internal.import(name, ctx.baseUrl) 导入
   （vendor/loader/src/config/tree.ts:122），解析父级是 profile 目录，因此命中本版新增的 profile 运行时解析器
   （默认 runtime 模式，apps/cli/src/profile-boot.ts:263）。
2. fallback 路由改用“条目声明者”作为解析父级
   （packages/boot/app-boot/src/profile-resolution/resolver.ts:693）。该路径位于 apps/cli/node_modules/... 之下，
   tsx 在那里不套用 tsconfig paths，于是按 exports 解析到 packages/core/tools/lib/index.js（构建产物）。
3. 该 lib 模块内部再 import 其它 dsh 包时，导入方文件位于 packages/** 下，tsx 在此会套用
   tsconfig.base.json:484 的 paths，于是解析到 packages/core/tools/src/index.ts（源码）。
4. 于是同一包存在两份实例。而 TOOL_RUNTIME_SCHEDULER 是
   Symbol('@deepseek-ai/dsh-tools.scheduler')（packages/core/tools/src/index.ts:463，不是 Symbol.for），
   两份实例的符号不相等，导致 packages/core/agent-loop/src/tool-calls.ts:170 的
   ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(...) 取到 undefined，同步抛出 TypeError —— 正好发生在
   appendToolCall 之后、结果产生之前，因此留下悬空的 tool/call。

最小验证（不需要调用模型）

# probe.mjs：export const url = import.meta.resolve('@deepseek-ai/dsh-tools')
# 放在 packages/core/agent-loop/lib/ 下（放其它包目录同样有效）

node -e "import('./packages/core/agent-loop/lib/probe.mjs').then(m=>console.log(m.url))"
# → file:///…/packages/core/tools/lib/index.js

node --import tsx/esm -e "import('./packages/core/agent-loop/lib/probe.mjs').then(m=>console.log(m.url))"
# → file:///…/packages/core/tools/src/index.ts

在 profile 目录（$DSH_HOME/profiles/web/）内做同样的探针，同样得到 lib/index.js；
两处结果比较：ToolRuntime 类不相等、TOOL_RUNTIME_SCHEDULER 不相等。
即：组合条目与其依赖落在两个不同的解析世界。

附带说明：不执行 pnpm run build 时，条目解析会直接 ERR_MODULE_NOT_FOUND（找不到 lib/index.js），
也就是构建产物在当前实现里是必需的，因此这个冲突在"文档规定的流程"下无法绕开。

Workaround（已验证可用）

不叠加 tsx 启动，全部走构建产物：

node apps/cli/lib/bin.js web

（改源码后需要重新 pnpm run build。）另外崩溃过的会话需要弃用、新开会话。

可能的修复方向

1. 让运行时路由的解析父级与 tsx 的解析世界一致（例如规范化到工作区真实包目录，使 paths 对条目同样生效 ⇒ 统一到 src），或反向把两边统一到 lib；
2. 或把跨包 seam 的 unique symbol 改为 Symbol.for(...)（TOOL_RUNTIME_SCHEDULER 等），让同进程内多副本仍能互通（治标，但改动极小）。

[Gniy7Ga]

Thanks for the detailed report and the Linux, macOS and Windows confirmations. We've linked this report to the existing investigation into source-launch tool scheduling failures, including the missing tool results that can prevent a failed session from continuing.

The built-entry workaround reported here is useful, but it is not evidence that existing failed sessions are repaired. We have not yet verified a publicly available release covering both normal tool execution and recovery of those sessions; we'll follow up here once that is confirmed.