dsh 0.1.6 alpha.2 版本，点了stop，大模型执行停不下来：Hierarchy Assistant Message Status Pending { queries:["VS Code webview \"Could not register service worker\" \"InvalidStateError\" \"The document is in an invalid state\"", "claude code vscode extension 加载 Web 视图时出错 Could not register service worker", "vscode webview service worker registration failed InvalidStateError fix"] } web_search Search the web for current information. Provide 1–4 queries in the required queries array. Returns an optional summary answer and a list of source URLs. { type:"object", properties:{queries: {type: "array", description: "Required search queries; accepts 1–4 items and merges their results.", items: {…}}}, required:["queries"] } Started 2026-10-12 16:28:54.689 Duration —

[wadeld123-oss]

提问了之后，大模型一直在执行，点了stop，停不下来，发新信息，被无视

[beenish-majeed]

你好，我不是维护者，下面是根据你贴的内容做的推测，不一定对。

你贴的信息里最关键的是这一行：web_search 的状态是 Pending，Duration 是空的。也就是说搜索请求发出去之后一直没有返回，这一轮卡在等它。这能解释你遇到的三个现象：

模型一直显示在"执行"：其实不是在生成，而是在等工具结果。
Stop 没用：它很可能只中断了模型的输出，没有取消正在等待的工具请求。
新消息被忽略：新消息大概排在没结束的这一轮后面，这一轮不结束就轮不到处理。

搜索为什么一直不返回，我只能猜：可能是搜索服务连不上，或者被网络/代理卡住，而且这个调用似乎没有超时。这需要日志确认。

现在可以试的办法

先等一两分钟，看会不会出现超时报错。
没反应的话，刷新页面或重新打开会话。刷新后如果这一轮已经结束，说明只是界面状态没同步。如果还是卡着，就是后端那一轮没有结束。
重启前先看一下，卡住之前模型有没有改文件、跑命令之类的操作。这次卡住的是搜索，副作用应该不大，但如果之后遇到别的工具卡住，不要直接重发，先确认实际执行结果，免得重复执行。
检查网络和代理设置，如果有关闭联网搜索的选项，可以先关掉再试。
这是 alpha 版本，可以在新会话里用最新版本再试一次，看看是不是旧版本的问题。升级前先备份重要会话。

给维护者的建议（如果上面的推测成立）

每个工具调用都应该有超时。
Stop 应该取消整个这一轮，包括正在等待的工具请求，并把 Pending 的工具标记为已取消。
Stop 之后输入框应该马上可用，不要继续排队等旧的这一轮。

想请楼主补充几点

操作系统，以及是桌面版、Web 版还是命令行
卡住后一共等了多久，有没有恢复
是不是每次联网搜索都会这样，其他工具会不会卡
有没有使用代理

另外，标题里贴了一大段界面内容，建议改成一句话描述，比如"Stop 无法中断卡在 Pending 的 web_search，之后的新消息也被忽略"，这样更容易被维护者看到。

[wadeld123-oss]

windows 11 ； web 版dsh卡住一个小时，没有返回，不影响其他会话，不像是网络代理问题；点stop也没停，输入新信息，没有处理

[wadeld123-oss]

报错：The tool call was interrupted after it was recorded, but no result was durably recorded. Its outcome is unknown. Decide whether to retry from the tool semantics: retry only if the operation is read-only or idempotent; if it may have side effects, first verify external state or ask the user. Do not retry blindly.
只能重启dsh后，修复

[beenish-majeed]

This looks like a tool-cancellation/lifecycle bug, not simply a network issue. web_search remains pending, Stop fails to terminate the in-flight operation, and the agent turn never closes, leaving subsequent messages unprocessed.

TOOL_OUTCOME_UNKNOWN is a recovery symptom: the tool call was recorded, but its result was never durably saved.

The fix should be in the backend: ensure Stop propagates cancellation to all active tool calls and parallel searches, enforce bounded cancellation so a hung tool cannot block the agent indefinitely, and reliably finalize the tool result and turn. Add a regression test that simulates a permanently hanging search, clicks Stop, and verifies that a new message is processed. Restarting DSH is recovery, not a fix.

[colehurwitz]

We hit the same symptom. Here is our best explanation of why the configured timeout and Stop don't end the call.

Environment: Linux, dsh 0.2.0-rc.2. A web_search call made inside a subagent stayed pending for 12+ minutes, although dsh-base configures searchTimeoutMs: 60000 and mounts dsh-tool-call-timeout-policy.

Likely cause: the timeout policy is cooperative by design. In its own words, it maps its own expiry to TOOL_TIMEOUT "without racing or abandoning the tool promise". At the deadline it aborts exec.signal and then keeps await next()ing. web_search forwards that signal to ctx.web.search(…, signal). If the search backend doesn't honour the signal (a stuck request, or a non-abortable step), the tool promise never settles, so the call hangs forever. Stop most likely aborts the same signal, which would explain why it has no effect either.

We didn't verify that the 60 s timer actually fired for the subagent's call, or which backend or request stalled; if the policy doesn't apply to subagent tool calls at all, that would be a separate gap.

Suggestions:

1. Make the search backend honour AbortSignal end to end, including the HTTP request.
2. For read-only, network-bound tools like web_search/web_fetch, consider a hard deadline: race the tool promise against the timer and return TOOL_TIMEOUT even if the tool hasn't settled. A hang then becomes an error the model can recover from.

Possibly related: #8827 (a workflow tool call that never returns).