[Bug] Web mode tool execution fails: Cannot read properties of undefined (reading 'prepare')

[tonyli3118]

Bug: Web mode tool execution fails — "Cannot read properties of undefined (reading 'prepare')"

Bug Description

In dsh web mode, any agent tool call (e.g. bash) fails immediately with:
Cannot read properties of undefined (reading 'prepare') (session records turn/end with reason.kind: "error", code: "UNKNOWN").
The UI shows the call as Interrupted with ~1ms duration.

The same environment works fine in headless mode (same profile config, same model, same working directory).

Environment

• dsh version: 0.1.1-rc.2 (@deepseek-ai/dsh)
• OS: Ubuntu 24.04
• Mode: dsh web (http://127.0.0.1:3080), profile web
• Model: any (reproduced with a locally served OpenAI-compatible model and with the default DeepSeek route)
• Working directory: any (reproduced under a plain home dir, an empty dir, and a dir with non-ASCII components)

Steps to Reproduce

1. Start dsh web (profile web)
2. Open http://127.0.0.1:3080, start a session
3. Send any message that makes the model call a tool, e.g. "列出当前目录内容" / "list current directory"
4. Model emits a bash tool call (pwd && ls), then the step fails:
   Cannot read properties of undefined (reading 'prepare')

Expected Behavior

The tool executes and the result is returned to the model (exactly as it does in headless mode).

Actual Behavior

Every tool call in web sessions fails with the prepare TypeError. Verified across multiple fresh sessions on the same host; headless on the same host/config/model/dir succeeds.

Root-cause analysis (from source)

• dsh-agent-loop calls ctx.tools[TOOL_RUNTIME_SCHEDULER].prepare(call.exec) (apps/../packages/agent-loop lib, around line 193).
• TOOL_RUNTIME_SCHEDULER is a symbol (Symbol("@deepseek-ai/dsh-tools.scheduler"), dsh-tools lib index.js ~2416) whose value is set as an instance field on the ToolRuntime service ([TOOL_RUNTIME_SCHEDULER] = { ... } in the ToolRuntime class, ~line 2564).
• In headless the composed profile has no dsh-agent-presets plugin (verified: 0 occurrences in --dump-config), so the agent's ctx.tools is the real ToolRuntime instance and the symbol property resolves.
• In web the profile includes dsh-agent-presets (default preset standard, 2 occurrences in --dump-config). The agent is assembled from the preset, and per the agent-presets docs the agent resolves its service views through the scope hierarchy (agent → preset → global). The scoped view of ctx.tools does not forward the symbol property, so ctx.tools[TOOL_RUNTIME_SCHEDULER] is undefined → .prepare throws.

Secondary observation: the web profile also ships tool-bash with disabled: true (dsh-web-app layer), yet the model-facing catalog still lists bash — enabling the tool via a user patch (disabled: false) does not fix the crash, confirming the missing scheduler (not the disabled flag) is the primary cause.

Suggested fix

• Make the scoped/proxied service view forward symbol-keyed properties, or
• Have dsh-agent-loop access the scheduler through a non-symbol key (e.g. a string-keyed accessor) that survives scope proxying.

Workaround

Use dsh --profile headless for tool-requiring tasks; web chat works as long as no tools are invoked.

[rob-x-ai]

I hit the same error with pnpm dsh web from a source checkout of 0.1.6-alpha.2 on macOS arm64 (Node 22.22.3).

In my case, the ESM fallback resolver passed a declaring package's symlinked node_modules path to tsx. That loaded built plugins alongside source dependencies, giving @deepseek-ai/dsh-tools two separate scheduler symbols. Resolving the declaring package's real path before delegating the import fixes it. I haven't verified whether this also explains the older npm release reported here.

• Patch and regression test in my fork
• Commit b8c177c5b2

The new test reproduces the exact prepare error without the fix and completes a real Bash turn with it. Local validation: 79 tests, build, typecheck, lint, and documentation checks passed. Since the contribution guide says external PRs aren't currently accepted, I'm sharing the patch here for review or cherry-picking.

---

我在 macOS arm64（Node 22.22.3）上从 0.1.6-alpha.2 源码运行 pnpm dsh web 时，也遇到了相同错误。

在我的环境中，ESM fallback 解析器将声明依赖的包在 node_modules 下的符号链接路径传给 tsx，导致已构建的插件与源码依赖混用。@deepseek-ai/dsh-tools 因此被加载两次，产生两个不同的 scheduler symbol。将声明包的路径转换为真实路径后再委托解析即可修复。目前还未确认这里报告的旧版 npm 安装是否也是同一原因。

上面链接到我 fork 中的 PR 和 commit，包含修复及回归测试：移除修复会重现 prepare 错误，恢复后真实 Bash 调用及整个轮次均能完成。本地 79 项测试以及构建、类型、lint 和文档检查均通过。看到目前暂不接受外部 PR，就先在这里分享补丁，供维护者审阅或 cherry-pick。

[zhang-guo-wen]

后续更新：0.1.6-alpha.2 的源码启动回归让本帖描述的“重复 dsh-tools + 本地 Symbol()”弱点变成了默认源码路径可稳定触发的问题。近期重复报告和完整修复方案已集中整理在 #7011 的这条回复。

完整修复需要同时处理两层：

• 解析层：tsx 源码启动默认 link，构建产物/pkg 使用 runtime，并在 profile/plugin 安装后拒绝重复核心包 realpath；
• 运行时层：scheduler 键改为 Symbol.for(...)，且在持久化 tool/call 前验证 scheduler，缺失时给出包含包路径和版本的 typed error。

这样既解决本帖的 profile/plugin 副本问题，也覆盖新的 src/lib 混载与 HMR 触发路径。