[BUG]pnpm dsh web：首次工具调用失败，提示“Cannot read properties of undefined (reading 'prepare')”，并导致会话永久中断

[wanyvfan]

Duplicate / related: this is the same defect already tracked in
#7273 Source launch crashes on every tool call
(the canonical thread, with a Collaborator reply) and analysed in
#7265,
#7338,
#7223.
Please follow #7273 for updates; I will not treat this post as a separate tracker.

What this post adds: the same split (lib/ row entries vs src/ imports from those entries)
reproduces on a stock profile with no profile-local plugins, from a fresh clone + fresh
pnpm install + fresh pnpm run build, and the probe readout is
service instanceof artifact-plane ToolRuntime: true, service[source scheduler] defined: false.

Summary

pnpm dsh web（源码启动）下，任何一次工具调用都会失败，并且会让该会话的日志永久不可用（后续每一轮请求都失败）。同一个 checkout 用产物平面启动（node apps/cli/lib/bin.js web）则一切正常。

Reproduction

已确认在全新 clone + 全新依赖 + 全新构建上必现，与本地环境状态无关：

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

然后在 GUI 里发一条会用到工具的指令（例如“查看当前文件目录”）。

Current behavior

1. 第一次工具调用时该轮直接以错误结束（会话日志中的 turn/end）：

{"type":"turn/end","data":{"turn":2,"reason":{"kind":"error","error":{"message":"Cannot read properties of undefined (reading 'prepare')","code":"UNKNOWN"}}}}

2. 该工具调用没有产生结果事件：整份日志 tool/call=1、tool/result=0。

3. 之后这个会话每一轮请求都失败：

• harness 自身的序列化器先拒绝：DeepSeek Messages tool calls need immediate results
  （packages/llm/llm-deepseek/src/protocols/messages/serialize.ts:117）
• 直连 API 时报 400：An assistant message with 'tool_calls' must be followed by tool messages responding to each 'tool_call_id'. (insufficient tool messages following tool_calls message)

即：一次工具基础设施故障会永久毁掉一个会话，只能新建会话。

Expected behavior

• 源码启动（pnpm dsh web）与产物启动（node apps/cli/lib/bin.js web）行为一致，插件解析只使用一个模块平面；
• 工具调用正常执行；
• 即使工具调度器失败，日志也应保持“可继续请求”的状态（不留下没有结果的 tool/call）。

Environment

• OS: Windows 11 (10.0.26100)，PowerShell
• Node: v24.12.0
• dsh: commit ddefc45fbc（0.1.6-alpha.2），源码启动 pnpm dsh web
• 对照：pnpm run build 之后 node apps/cli/lib/bin.js web 正常

根因（供参考，附最小证据）

TOOL_RUNTIME_SCHEDULER 是按模块实例生成的 unique symbol（packages/core/tools/src/index.ts:463），agent-loop 用它取调度器（packages/core/agent-loop/src/tool-calls.ts:170：ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(...)）。

源码启动时同一个进程里存在两份 @deepseek-ai/dsh-tools：

• 插件行经 profile 解析落到构建产物 packages/core/tools/lib/index.js；
• 仓库内文件的裸导入被 tsx 的 tsconfig paths 映射到源码 packages/core/tools/src/index.ts。

在一个真实 profile boot（--profile acp）里挂探针读取，结果：

service instanceof artifact-plane ToolRuntime: true
service instanceof source-plane ToolRuntime: false
service[source scheduler] defined: false     ← agent-loop 侧拿到的符号
service[artifact scheduler] defined: true

因此 agent-loop 查到的调度器是 undefined。这与仓库约定 “Source plane vs artifact plane, never mixed” 冲突。

修复方向（本地已验证、未提交）：让 profile 解析跟随启动平面——源码启动时，把解析到 lib/**/*.js 的条目改投存在的 src/**/*.ts(x)；生成的 host 产物与浏览器/Worker 打包件没有对应源码，继续留在 lib/；Worker 因为没有 tsx hook 固定产物平面。相关位置：packages/boot/app-boot/src/profile.ts、packages/boot/app-boot/src/profile-resolution/resolver.ts。

另一个相关缺陷（同一条因果链的第二段）

工具组失败后，已经写入的 tool/call 不会补结果（packages/core/agent-loop/src/tool-calls.ts 的现有设计注释是 “without fabricating results”），于是日志永久停在“assistant 带 tool_calls 但没有结果”的状态。崩溃恢复路径（packages/core/session/src/repair.ts 的 interruptedTurnClosers）已经有同类语义（TOOL_OUTCOME_UNKNOWN），建议实时失败路径也补一条结果，避免一次故障毁掉会话。

---

Body (English)

Summary

With a source launch (pnpm dsh web), every tool call fails, and the failure permanently breaks the session: all later requests in it fail too. The same checkout launched from built artifacts (node apps/cli/lib/bin.js web) works.

Reproduction

Reproduced on a fresh clone + fresh install + fresh build:

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

Then send any prompt that uses a tool (for example “list the current directory”).

Current behavior

1. The first tool call ends its turn with an error (turn/end in the session log):

{"type":"turn/end","data":{"turn":2,"reason":{"kind":"error","error":{"message":"Cannot read properties of undefined (reading 'prepare')","code":"UNKNOWN"}}}}

2. The call has no result event: the log contains tool/call=1, tool/result=0.

3. Every later request in that session then fails:

   • the harness serializer rejects it first: DeepSeek Messages tool calls need immediate results
     (packages/llm/llm-deepseek/src/protocols/messages/serialize.ts:117)
   • a direct provider call returns 400: An assistant message with 'tool_calls' must be followed by tool messages responding to each 'tool_call_id'.

Expected behavior

• A source launch behaves like a built launch: plugin resolution stays on one module plane.
• Tool calls execute normally.
• A tool-scheduler failure leaves the log requestable (no tool/call without a result).

Environment

• OS: Windows 11 (10.0.26100), PowerShell
• Node: v24.12.0
• dsh: commit ddefc45fbc (0.1.6-alpha.2), source launch pnpm dsh web
• Control: node apps/cli/lib/bin.js web after pnpm run build works

Root cause (with minimal evidence)

TOOL_RUNTIME_SCHEDULER is a unique symbol created per module instance (packages/core/tools/src/index.ts:463), and the agent loop reads the scheduler through it (packages/core/agent-loop/src/tool-calls.ts:170: ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(...)).

A source launch loads two copies of @deepseek-ai/dsh-tools in one process:

• plugin rows resolve through the profile to the built artifact packages/core/tools/lib/index.js;
• bare imports inside the repository are projected by tsx's tsconfig paths to the source file packages/core/tools/src/index.ts.

A probe mounted in a real profile boot (--profile acp) reads:

service instanceof artifact-plane ToolRuntime: true
service instanceof source-plane ToolRuntime: false
service[source scheduler] defined: false     ← the symbol the agent loop holds
service[artifact scheduler] defined: true

So the scheduler lookup in the agent loop is undefined, contradicting the repository rule “Source plane vs artifact plane, never mixed”.

Fix direction (verified locally, uncommitted): make profile resolution follow the launch plane — under a source launch, a routed entry that resolves into lib/**/*.js moves to the matching src/**/*.ts(x) when it exists (generated host artifacts and bundled browser/Worker payloads keep the artifact); Workers stay on the artifact plane because they have no tsx hook. Files: packages/boot/app-boot/src/profile.ts, packages/boot/app-boot/src/profile-resolution/resolver.ts.

Related second defect

When a tool group fails, already-written tool/call events receive no result (packages/core/agent-loop/src/tool-calls.ts documents “without fabricating results”), leaving the log permanently in an “assistant with tool_calls and no results” state. Crash repair already models this case (packages/core/session/src/repair.ts, TOOL_OUTCOME_UNKNOWN); the live failure path should record the same kind of result so one failure cannot destroy a session.

[springsky1]

新版本修复了这个bUG 不过又引入了几个新BUG

[springsky1]

你可以使用 node apps/cli/lib/bin.js web 方式启动就不会有那个报错了 可以保持当前版本 新版修改了消息和历史对话 会导致有插件的时候 直接无法读取历史消息 也无法发送对话，还有一点UI的BUG 等

[wanyvfan]

感谢，用这条命令可以运行