工具执行失败后出现未配对的 tool_call，导致整个 Session 无法继续使用

[wakakakahahaha]

我在使用 DeepSeek Harness 时遇到了一个可以重复出现的问题：
当某次 Tool 执行发生异常后，当前 Session 会进入无法继续正常对话的状态。
最开始 Tool 执行时报错：

Cannot read properties of undefined (reading 'prepare')
在这个错误出现之后，即使我只是发送一条普通消息，例如：111
也会继续报错：
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)
此后这个 Session 无法继续正常对话。
第一次出现问题时的操作过程
第一次遇到这个问题时，我正在让 DSH 帮我创建一个 Plugin。
大致过程是：
我要求 Agent 创建一个新的 Plugin。
Plugin 创建任务似乎没有完整执行结束。
Agent 提示我需要重启 DSH。
我重启了 DSH。
重启之后，Agent 尝试继续处理之前的任务，并开始读取之前的状态 / cache。
在执行相关 Tool 时出现：
Cannot read properties of undefined (reading 'prepare')
此后继续发送普通消息，就出现：
An assistant message with 'tool_calls' must be followed by tool messages responding to each 'tool_call_id'.
最开始我怀疑这是由于 Plugin 创建任务没有完成，又恰好发生了 restart，导致 Session 恢复状态出现问题。
但是在新的 Session 中也可以出现类似问题.
后来我创建了一个全新的 Session 进行测试。
在新的 Session 中，正常对话没有问题。
但当我让 Agent 执行一个需要调用 Tool 的任务（当时是让它读取 / 检查一个空的 cache）时，再次出现：
Cannot read properties of undefined (reading 'prepare')
随后这个新的 Session 也无法继续正常对话。
发送普通消息后同样出现：
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)
因此我现在怀疑，这个问题可能并不只是 restart / Session restore 导致的，而可能与 Tool execution failure 的异常处理有关。

[wakakakahahaha]

[linjinquan2020]

我也遇到了类似的问题

[wakakakahahaha]

我的初步理解
我阅读了一部分当前实现，但不确定自己的理解是否完全正确。
从现象来看，我怀疑可能存在这样的情况：
assistant
↓
产生 tool_call (call_id = 123)
↓
tool/call 被记录
↓
Tool Runtime / Scheduler 开始执行
↓
prepare() 阶段发生异常
↓
没有产生对应的 tool/result
最终模型可见的 conversation history 中可能出现：
assistant -> tool_call(call_id=123)

[缺少对应的 tool_result]
当下一次向 Model Provider 发起请求时，由于之前的 tool_call 没有对应的 Tool Message / tool_result，导致 conversation transcript 不符合 Tool Calling protocol，于是 Provider 拒绝后续请求：
An assistant message with 'tool_calls' must be followed by tool messages responding to each 'tool_call_id'.

[zoahdev]

This is the #1697 family ? the exact crash string (Cannot read properties of undefined (reading 'prepare')) is the dual-instance TOOL_RUNTIME_SCHEDULER symbol mismatch. The session getting stuck afterwards is the second-order effect: prepare throws before the tool message is produced, so the assistant turn is left with an unpaired tool_call, and the session state machine refuses every following message.

Confirm in 10 seconds

npx dsh-plugin-doctor --profile ~/.dsh/profiles/web --json

If profile-shadow is fail, a hoisted real-directory @deepseek-ai/dsh-tools copy is shadowing the host ? that is the #1697 precondition. Exit code 2.

Permanent fix (staged)

• One-line Symbol.for + protocol-version guard on the fork branch: https://github.com/zoahdev/deepseek-harness/tree/fix/tool-runtime-scheduler-symbol-for
• Same class triage lives in dsh-plugin-doctor (profile-shadow check, v1.6.0): https://github.com/zoahdev/dsh-plugin-doctor/releases/tag/v1.6.0

Recovering the stuck session: the crash left the loop in a state it cannot unwind; start a new session (or restore one) after applying the profile fix. If you can share dsh-plugin-doctor --profile ... --json output + the exact plugin install step, that pins which path triggered the hoist.

[wakakakahahaha]

Thanks! I tried the command, but npx installs ***@***.*** instead of v1.6.0, and this version doesn't recognize the --profile option: PS C:\Users\Administrator> npx dsh-plugin-doctor --profile ~/.dsh/profiles/web --json Need to install the following packages: ***@***.*** Ok to proceed? (y) y error: unknown option '--profile' Should I install/run v1.6.0 directly from the GitHub release instead? 刘鑫 ***@***.***

[Electricitysheep]

工具执行失败后留下未配对 tool_call → 会话卡死——和 #1473/#1497（损坏会话拖垮）、#739（序列化不一致）都是"状态不一致"家族。

临时：这个会话基本废了，开新会话最省事；官方应修"工具失败后清理/回滚 tool_call 状态"。排查思路见 FAQ：https://github.com/Electricitysheep/dsh-handbook/blob/main/docs/faq.md

[wakakakahahaha]

我又做了一个全新 Session 的最小测试：先询问 1+1，正常；再询问 TCP 协议含义，正常；随后要求查找当前目录，第一次进入 Tool execution 后立即出现 Cannot read properties of undefined (reading 'prepare')。因此看起来纯 Model 请求正常，而任何实际 Tool execution 都会触发该错误。 刘鑫 ***@***.*** 原始邮件 发件人：Zhou Yuchen ***@***.***> 发件时间：2026年8月15日 17:28 收件人：deepseek-ai/deepseek-harness ***@***.***> 抄送：wakakakahahaha ***@***.***>, Author ***@***.***> 主题：Re: [deepseek-ai/deepseek-harness] 工具执行失败后出现未配对的 tool_call，导致整个 Session 无法继续使用 (Discussion #1841) 工具执行失败后留下未配对 tool_call → 会话卡死——和 #1473/#1497（损坏会话拖垮）、#739（序列化不一致）都是"状态不一致"家族。 临时：这个会话基本废了，开新会话最省事；官方应修"工具失败后清理/回滚 tool_call 状态"。排查思路见 FAQ：https://github.com/Electricitysheep/dsh-handbook/blob/main/docs/faq.md — Reply to this email directly, view it on GitHub, or unsubscribe. Triage notifications, keep track of coding agent tasks and review pull requests on the go with GitHub Mobile for iOS and Android. Download it today! You are receiving this because you authored the thread.

[zoahdev]

Companion spec for the force-interrupt gap (also raised in #1856): a minimal CLI-level escape hatch for stuck turns.

Proposal: dsh turn abort

• dsh turn abort --profile P [--session S] ? force-terminates the active turn's tool execution and returns the session to a clean state (or marks it unrecoverable when the loop state cannot unwind).
• Exit codes: 0 aborted cleanly, 1 nothing running, 2 could not abort (state unrecoverable; message says restart).
• Safety: only aborts the current turn, never deletes sessions or inbox messages.

Why it matters

Both #1841 (unpaired tool_call) and #1856 (third-party scan hangs) end in sessions that cannot be interrupted from the UI; users currently must restart the whole dsh web process. A CLI escape hatch is small, testable, and gives operators a recovery path without killing the server.

Implementation surface (candidate)

• agent-loop exposes an abortTurn() on the session handle (kill active tool execution, cancel pending next-step queue, mark turn terminal).
• dsh turn abort calls it; --json returns the resulting session state.

Happy to draft the full RFC or a reference implementation (dsh-plugin-doctor could ship a turn abort diagnostic wrapper while upstream decides).

[wakakakahahaha]

找到问题了找到问题了，感谢感谢 刘鑫 ***@***.***