Bug: agent loop crashes after bash tool call — 'Cannot read properties of undefined (reading \'prepare\')' kills session (3 consecutive turns)

[SilenZerOrz]

"## \ud83d\udc1b Bug Report\n\nThe agent loop crashes mid-turn with a raw Node.js runtime error, terminating the turn as error with code UNKNOWN. The turn logs step/end immediately after a tool/call is issued and never produces a tool/result \u2014 the engine dies instead of letting the tool complete.\n\n### Error\n\nCaptured from the session event log (turn/end reason):\n\n\nCannot read properties of undefined (reading 'prepare')\ncode: UNKNOWN\n\n\nIt happened three turns in a row (turn 14, 15, 16), so it's consistently reproducible in this session rather than a one-off glitch \u2014 it effectively killed the whole session.\n\n### Steps to reproduce\n\n1. Run dsh in a session (web/headless profile).\n2. Have the agent issue a bash tool call (in our case a network-connectivity diagnostic using curl).\n3. Observed sequence in the session log:\n - tool/call (bash) \u2014 emitted\n - step/end \u2014 emitted immediately (no tool/result was ever written)\n - turn/end with reason: {kind: \"error\", error: {message: \"Cannot read properties of undefined (reading 'prepare')\", code: \"UNKNOWN\"}}\n\nThe stack originates inside the harness when it tries to prepare something (tool prepare path / prepareProfile) and dereferences a property on undefined.\n\n### Expected vs Actual\n\n- Expected: the bash tool runs, returns a tool/result, and the loop continues. A runtime error like this should not abort the session.\n- Actual: the turn aborts with turn/end(error) and no tool/result is produced; recurs on 3 consecutive turns.\n\n### Environment\n\n- dsh version: 0.1.0-rc.8 (npm @deepseek-ai/dsh; latest on npm is 0.1.1-rc.2)\n- OS: macOS (Apple Silicon Mac Mini)\n- Node: v22.x\n- Session policy: workspace-write, approval ask\n- Model used by session: DeepSeek-V4-Flash\n\n### Additional context\n\n- A related (distinct) symptom in the same session: the web_search tool returned Error: Authentication Fails, Your api key: ****0700 is invalid (code WEB_PROVIDER_ERROR) \u2014 the configured search tool key was invalid. The crash happened while the agent was falling back to curl network checks.\n- The crash triggers right after a tool/call for bash; likely area to inspect is the tool prepare/result-handling path.\n\nFull session event log (session.jsonl) showing the three turn/end error events is available on request.\n"

[tancheng33]

Same error string as #4529, which got a confirmed root cause yesterday — so start there.

Confirmed mechanism (from #4529): TOOL_RUNTIME_SCHEDULER is a plain Symbol(), not Symbol.for() (packages/core/tools/src/index.ts:466). A second copy of @deepseek-ai/dsh-tools anywhere earlier in Node's parent-directory walk — concretely $DSH_HOME/profiles/<profile>/node_modules/@deepseek-ai/dsh-tools — means the live ToolRuntime instance carries a different key than the one dsh-agent-loop reads at packages/core/agent-loop/src/tool-calls.ts:169. The lookup returns undefined, and .prepare on it produces exactly your message. The duplicate typically lands via npm install <plugin> inside the profile dir: npm ≥7 auto-installs the plugin's peer set, duplicating core packages. dsh plugin (pnpm, autoInstallPeers: false) does not do this.

Check (macOS): ls ~/.dsh/profiles/*/node_modules/@deepseek-ai/ — any dsh-* directory there is a suspect; rename it away and rerun.

One detail in your report cuts against the static-duplicate theory, and it is the discriminating question: your web_search call earlier in the session returned a typed WEB_PROVIDER_ERROR — a real tool result, meaning the scheduler was alive at that point. A boot-time duplicate fails on the first tool call, not the fourteenth. So:

1. Does a brand-new session crash on its first tool call right now? (yes → static duplicate, check above)
2. Were turns 14–16 in a resumed/relaunched process? Installing or updating anything under the profile dir between the original run and the resume would make the crash appear mid-session while actually being present from that process's first tool call.
3. If neither — something mutated the module graph in-process (plugin self-install, HMR). List what you had mounted beyond the stock profile.

For maintainers, two hardening notes (carried over from #4529): Symbol.for('@deepseek-ai/dsh-tools.scheduler') makes the slot duplicate-tolerant; alternatively, an explicit undefined check at the call site that throws a typed error naming the duplicate-module possibility would turn this from an UNKNOWN TypeError into a five-minute fix. The headless runner also still prints only error.message on abort (packages/bundle/headless/src/index.ts:131) — gating the stack behind a flag would have saved both reporters a source dive.

Separately: if that session now rejects every request with 400 INVALID_REQUEST, that is the dangling tool/call recovery gap tracked in #4549 — related symptom, different fix.

[SilenZerOrz]

后续复现与根因确认（web profile / GUI 环境）

在 #4601 原帖的 web profile / GUI 场景下，我们继续排查并拿到了完整证据链。整体证实了 #4529 的静态符号机制，但具体触发路径与"第二份 dsh-tools"略有不同 —— 特此汇报，供维护者参考。

环境快照（仅与本 bug 相关）

• dsh：0.1.1-rc.2（npm 全局安装，与上游 master dsh-v0.1.1-rc.2 完全对齐，CLI 无任何本地改动）
• 运行：dsh web --no-open，http://127.0.0.1:3080/
• profile：web
• 状态：curl :3080 长期 HTTP 200，服务层从未 crash

一、会话级证据（来自完整 session.jsonl，可提供全文）

对崩溃会话逐 turn 统计 tool/call 与 tool/result：

turn	tool/call	tool/result	结果
1–13	全部=result 数	全部配对	✅ 正常
14/15/16	1	0	❌ prepare 崩溃
18–23	各 1	0	❌ prepare 崩溃（6 连）
24 → 用户重启/resume 后	全部配对	全部配对	✅ 恢复

铁证链：

1. turn 1–13 完全正常（每个 tool/call 都有对应 tool/result）
2. turn 14 起每次 tool/call 序列为 tool/call → step/end → turn/end(reason.error "Cannot read properties of undefined (reading 'prepare')", code UNKNOWN)，tool/result 从未写出，共 10 个连续 turn 崩溃（比原帖"3 个"更严重）
3. 崩溃不影响纯文本回复（无 tool 的 turn 正常 turn/end completed）—— 与 --profile headless crashes on any tool call: "Cannot read properties of undefined (reading 'prepare')" (0.1.1-rc.2) #4529 作者观察一致：模型/provider 路径健康，故障在 tool 分发层
4. 同一会话内用户重启后 resume 即恢复（reason:"resume"）—— 对应 --profile headless crashes on any tool call: "Cannot read properties of undefined (reading 'prepare')" (0.1.1-rc.2) #4529 维护者给出的判别问题 #2"是否在 resume/relaunch 进程里"：是。崩溃在进程生命周期内 mid-session 出现，与静态启动重复略有差异

二、复现（可稳定复现）

• 崩溃 turn 18 的 bash 命令恰好是安装/首次触碰某第三方视觉插件的 mkdir .../.dsh-vision-toolkit/tmp/... —— 即在崩溃瞬间用户正在触碰该插件，随后 turn 19/20 读该插件相关路径
• 禁用该第三方视觉插件（disabled: true）并重启 dsh web 后，新会话工具全部恢复正常（bash/read/glob 均返回结果）
• 该插件 enable/disable 是"能否稳定再现"的开关，可复现

三、本地包层证据（对照 #4529 的"第二份 dsh-tools"）

• 全盘扫描 node_modules/@deepseek-ai/dsh-tools：仅 1 份（在全局 dsh CLI 内），没有 profile 内副本
• 但 profile node_modules/@deepseek-ai/ 下存在 3 个额外核心包（dsh-credentials、dsh-home-paths、dsh-typert-protocol），其版本为 0.1.0-rc.8，晚于全局 CLI 的 0.1.1-rc.2（版本漂移）
• 已确认 packages/core/tools 中 TOOL_RUNTIME_SCHEDULER = Symbol("@deepseek-ai/dsh-tools.scheduler") 是普通 Symbol() 而非 Symbol.for()（本机 0.1.1-rc.2 存在）

结论修正：本机并非"存在第二份 dsh-tools"，而是第三方插件通过其 peerDependencies 在 profile 内拉进了多份版本漂移的核心 @deepseek-ai/dsh-* 包（0.1.0-rc.8 ≠ 全局 0.1.1-rc.2），破坏了 TOOL_RUNTIME_SCHEDULER 的 Symbol 一致性，导致 registry[TOOL_RUNTIME_SCHEDULER] 取到 undefined，.prepare 崩。禁用该第三方插件即移除了注入源，Symbol 恢复一致，工具恢复。根因与 #4529 归属同一机制（Symbol() 非 Symbol.for() 对重复加载不健壮），但触发载体从"静态二次安装"扩展到了"第三方插件 peer 依赖在 profile 内的版本漂移"。

四、对维护者的两点建议（呼应 #4529）

1. Symbol.for('@deepseek-ai/dsh-tools.scheduler') 可消除重复/漂移副本的差异（已在 --profile headless crashes on any tool call: "Cannot read properties of undefined (reading 'prepare')" (0.1.1-rc.2) #4529 提过，再次附议）
2. 建议为 registry[TOOL_RUNTIME_SCHEDULER] 命中 undefined 时输出可行动诊断（命名可能的本机重复/漂移来源，而非裸 UNKNOWN TypeError）—— 本次排查花费大量人时才找到根因，因为错误被统一抹平成 UNKNOWN，且崩溃发生在 web 会话内、不落 stderr。

附：诊断配方（便于维护者/用户复现定位）

# 1. 服务层 vs 客户端层分离
curl -s -o /dev/null -w "HTTP %{http_code}\n" http://127.0.0.1:3080/   # 服务一直 200
# 2. 崩溃在 web 会话 log（不落 stderr）：解析 session.jsonl 找 turn/end error
# 3. 全盘找 dsh-tools 副本 + profile 核心包版本漂移
find ~/.dsh ~/.npm-global -type d -name dsh-tools 2>/dev/null
ls ~/.dsh/profiles/web/node_modules/@deepseek-ai/   # 版本 vs 全局 dsh，找漂移
# 4. 二分 disable 第三方插件（本机罪魁为该视觉插件）

[SilenZerOrz]

补充复现诊断附件（gist）：

📎 https://gist.github.com/SilenZerOrz/71fd96f3d22a26490c8e2d84522f35fc

内含：

• dsh-4601-event-skeleton.md — 崩溃会话完整事件骨架（1355 条，仅结构化事件：turn/start · turn/end(error) · step · tool/call · tool/result；对话正文/命令参数/文件路径已全部脱敏）。
• turn_summary.py — 逐 turn 统计 tool/call 与 tool/result 配对的可复现脚本，可对任意 session.jsonl 重跑。
• README.md — 核心结论摘要。

复现命令：

python3 turn_summary.py session.jsonl

直接复现本报告的 J 型故障（turn 1–13 全部 tool 有 result → turn 14–23 每次 tool/call 后 step/end 无 tool/result 即崩 prepare undefined → 重启/resume 后恢复）。

完整原始 session.jsonl（约 7.2 MB）含工作内容未公开上传，需要可另行提供。

[denial123789]

The event skeleton adds an important discriminator: this is not enough evidence to label the incident a static duplicate present at process boot. The join that matters is tool history + Host process generation.

• If turns 1–13 and 14–23 ran under the same PID/boot generation, a startup-only duplicate cannot explain the transition; capture plugin mount/update/disposal/HMR and ToolRuntime generation around turn 14.
• If the Session was resumed in a new process before turn 14, it can still be that new process's first scheduler lookup, so the late turn number is misleading.
• Restart restoring service without a disk change is strong process-state evidence, but disabling a plugin plus restarting changes two variables. It identifies a useful trigger boundary, not which variable repaired the slot.

One attribution detail is also worth tightening: TOOL_RUNTIME_SCHEDULER is minted by @deepseek-ai/dsh-tools. Finding version-drifted dsh-credentials, dsh-home-paths, or dsh-typert-protocol proves closure risk, but those packages alone do not mint a second scheduler symbol. A direct symbol-identity claim still needs a second evaluation/resolution edge for dsh-tools (physical duplicate, loader generation, HMR re-evaluation, or equivalent).

The unpaired tool/call is a separate durability consequence. Preserve it; recovery should append a truthful typed “not started” outcome only when the runtime can prove dispatch never crossed the missing scheduler boundary, rather than deleting history or inventing success.

I incorporated the new evidence into a revised source-backed failure router and recovery contract: https://sandbaseai.github.io/deepseek-harness-handbook/duplicate-core-runtime.html

Disclosure: I maintain the independent community handbook linked above.

[SilenZerOrz]

感谢两轮审阅（tancheng33 / denial123789）。按"需要找到 dsh-tools 的第二条求值边"的方向做了针对性验证，结果如下。

事实：profile 内存在第二份 dsh-tools（version drift）

全局  ~/.npm-global/lib/node_modules/@deepseek-ai/dsh/node_modules/@deepseek-ai/dsh-tools
      → version 0.1.1-rc.2
      → lib/index.js:2416  const TOOL_RUNTIME_SCHEDULER = Symbol("@deepseek-ai/dsh-tools.scheduler")

profile  ~/.dsh/profiles/web/node_modules/@deepseek-ai/dsh-tools（实体目录，非 symlink）
      → version 0.1.0-rc.8
      → lib/index.js:2416  同字符串，但每次 Symbol() 调用产生不同实例

两份是不同物理文件、不同版本。普通 Symbol() 每次调用生成唯一实例，即使字符串相同也不相等；因此跨份读取 registry[TOOL_RUNTIME_SCHEDULER] 时，若 Key 来自另一份 dsh-tools，即返回 undefined。

谁把它拉进 profile（均声明为 dependencies 直接依赖，非 peer）：

• dsh-obsidian "@deepseek-ai/dsh-tools": "*"
• dsh-better-sidebar "^0.1.0-rc.8"
• dsh-chat-import / dsh-recall "^0.1.0-rc.6"
• dsh-univer-office "0.1.0-rc.8"（固定旧版本）

这些第三方插件把 @deepseek-ai/dsh-tools 当直接 dependency 安装进 profile，pnpm 解析到 0.1.0-rc.8（旧于全局 0.1.1-rc.2），构成版本漂移的第二条求值边。

时间限定（诚实说明）

崩溃发生时（turn 14）profile 是否已存在这份第二 dsh-tools，无法回溯确认——它由后续 pnpm install（装插件）落盘，崩溃后的磁盘状态与崩溃当时未必相同。因此：

• 已确证：此刻存在第二份 dsh-tools（0.1.0-rc.8）；其来源是第三方插件的直接 dependency；机制（普通 Symbol() 对重复加载不健壮）成立。
• 未完全实锤：turn14 崩溃当时 profile 已含此副本。二者是否为同一时刻状态，需在崩溃前/后的干净环境下做 A/B 方可定论。