All tool calls fail with "Cannot read properties of undefined (reading 'prepare')" on a fresh profile

[hldz-top]

Summary

Every tool call fails immediately with Cannot read properties of undefined (reading 'prepare') on a completely fresh, vanilla profile with zero third-party plugins. Plain chat (no tools) works fine every time; the moment the model calls any tool — a third-party plugin's tool or a shipped built-in one — the run crashes.

Reproduction (minimal, no third-party plugins involved)

# Fresh profile from the shipped template, nothing else installed
dsh --profile my-clean-test --from-default-profile headless
dsh --profile my-clean-test "读取文件 /path/to/any/file.txt 的前 3 行内容并告诉我"

Output:

dsh: reasoning:
The user is asking me to read the first 3 lines of ... Let me just use the read tool with limit 3.

dsh: UNKNOWN: Cannot read properties of undefined (reading 'prepare')
[ELIFECYCLE] Command failed with exit code 1.

The model's reasoning shows it correctly decided to call the built-in read tool; the crash happens at the moment of actually dispatching that call. A prompt with no tool need ("你好,用一句话回复即可") completes normally (exit 0, correct reply) every time.

What I ruled out

• Not a specific plugin. Reproduced identically with: (a) a third-party plugin's own tools, (b) dsh's own built-in read/bash tools, (c) a profile that has never had any third-party plugin installed or referenced anywhere (no dsh.profile.bundles entry, no home-level cordis.patch.yml row).
• Not stale build artifacts. A full pnpm install --frozen-lockfile && pnpm run build (clean exit, no errors) did not change the symptom.
• Not plain generation/chat. Only reproduces once a tool call is actually dispatched.

Likely crash site

packages/core/agent-loop/src/tool-calls.ts:

const prepared = await ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(call.exec)

ToolRuntime (packages/core/tools/src/index.ts) assigns [TOOL_RUNTIME_SCHEDULER] as an unconditional class-field initializer:

readonly [TOOL_RUNTIME_SCHEDULER]: ToolRuntimeScheduler = {
  prepare: exec => this.prepareScheduledExecution(exec),
  ...
}

Since that assignment can't be skipped once the constructor runs, ctx.tools[TOOL_RUNTIME_SCHEDULER] reading as undefined at the point tool-calls.ts uses it points at ctx.tools not being the same ToolRuntime instance/module-identity that defined the symbol — the shape of a dual-package-instance / symbol-identity mismatch, not a missing-property bug. I haven't traced further into the Loader/host-runner internals to confirm exactly where the two copies would come from.

Environment

• Commit: ddefc45fbc7f8e46dd73185e68295696d1297887 (repo has local uncommitted changes — see below — but they're confined to packages/web/web-fetch-http/* and unrelated docs/lockfile, not agent-loop/core/tools)
• Node: v24.18.0, pnpm: 11.7.0
• macOS, Apple Silicon
• dsh launched from source (pnpm dsh ...), both web and headless profiles affected

Note on the local checkout

This checkout has an unrelated in-progress local change (an HTML-decoding fix under packages/web/web-fetch-http) that I can't rule out interacting with this somehow, though the touched files don't overlap with the tool-execution code path above. If anyone can reproduce (or not) on a clean git clone at this same commit, that would help separate "real regression at this commit" from "something specific to one local tree."

Happy to run additional diagnostics against this reproduction if useful — this currently blocks all tool-calling, which is a pretty core piece of functionality.

[World-sudo]

#7079
try this command
node apps\cli\lib\bin.js web

[hldz-top]

感谢，本地已经能跑

[World-sudo]

没事，后续等开发者修复吧