[Bug][Windows] 工具调用永久卡死：runner 已 fork、IPC 已连上，但 start 请求丢失 —— WindowsJobRunner 无启动超时、pendingCalls 无看门狗（0.1.7-rc.2 → 0.2.1-alpha.2 均复现）

[pigstrong9]

环境

• @deepseek-ai/dsh：0.1.7-rc.2（9/28 起）与 0.2.1-alpha.2（当前，npm dist-tag alpha；latest=0.2.0-rc.2）
• Windows x64，官方安装器自带的 Node，dsh web 模式（127.0.0.1:3080），文件策略 danger-full-access（不涉及沙箱 ACL 路径）
• 单用户、同时开多个 GUI 会话

症状

偶发某个工具调用永远不返回，GUI 一直显示执行中（最长一次 2 小时+）。4 天共 12 例，三个通道都中招：pwsh 命令、git 自动检查点（git status --porcelain / git add --all）、@vscode/ripgrep 代码搜索。服务器主进程全程健康（其他会话正常推进），杀掉问题进程后卡住的会话 2 秒内自动恢复、零数据丢失（12/12 验证）。

12 例台账：9/28 ×7（mvn构建、git add ×2、git status、pwsh、ripgrep ×2）、9/29 ×2、10/10 ×2、10/12 ×1；另有 2 例更严重的「派发丢失」变体（连 runner 都没 fork 出来，只能靠点「停止」触发 turn/end 强制清队列）。

诊断证据

1. 卡住的调用的 runner.js 子进程已 fork、IPC 已连接，但目标命令从未启动：0 个子进程、CPU 累计 0.02~0.08s（一例挂了 27 小时仍如此）；某案例中命令重定向的日志文件根本没被创建。
2. @deepseek-ai/dsh-subprocess-local/lib/runner.js（在 0.2.1-alpha.2 上逐行验证，L151/L177/L188 startSeen）等待 IPC start 请求没有任何超时——全文件 setTimeout 出现 0 次，出路只有断连→finish(127) 和目标退出两条。start 消息一丢 = 双方永久互等。
3. sessionStats.pendingCalls（@deepseek-ai/dsh-session-stats/lib/index.js:129-152）只有 tool/result 和 turn/end 两条出路，全链路无任何看门狗/超时。
4. 恢复验证（12/12）：Stop-Process 杀掉僵尸 runner → 断连使 harness 合成 result → 该会话投影 mtime 立刻前进、pendingCalls 清空、会话继续，无需任何修复操作。
5. 与负载和 uptime 无关：10/12 那例发生在服务器启动后仅 10 分钟。
6. 与插件无关：所有卡住进程都是核心包 dsh-subprocess-local/lib/runner.js；start 握手是 server↔runner 私有 IPC，插件无代码路径可达；git 自动检查点是纯核心行为；跨版本（0.1.7→0.2.1）、多次重启服务器均复现。

期望行为

工具调用不应存在「永久挂起」状态。两处各补一个超时即可根治：

1. runner.js：IPC 通道建立后即计时，N 秒（如 10~15s）内未收到 start → 自杀并带结构化错误退出；
2. dsh-session-stats：pendingCalls 加看门狗（可配置，如 5min），把丢失的子进程调用合成为错误 tool/result，而不是让整个 turn 无限挂起。

（可选第三条：harness↔runner IPC 加应用层心跳，检测半开连接。）

僵尸检测脚本（我用来回收 12 例的判据：runner 存活≥3min 且 0 子进程 且 CPU<1s）

$server = Get-CimInstance Win32_Process -Filter "Name='node.exe'" |
  Where-Object { $_.CommandLine -match 'dsh.*bin\.js.*web' } | Select-Object -First 1
Get-CimInstance Win32_Process -Filter "ParentProcessId=$($server.ProcessId)" |
  Where-Object { $_.CommandLine -match 'runner\.js' } | ForEach-Object {
    $p = Get-Process -Id $_.ProcessId
    $kids = @(Get-CimInstance Win32_Process -Filter "ParentProcessId=$($_.ProcessId)").Count
    if (((Get-Date) - $p.StartTime).TotalMinutes -ge 3 -and $kids -eq 0 -and $p.CPU -lt 1) {
      "ZOMBIE PID $($_.ProcessId) age=$([int]((Get-Date)-$p.StartTime).TotalMinutes)min" } }

相近帖（症状同族、机制不同，建议交叉链接）

• Desktop (Windows): shell tool calls hang forever under workspace-write sandbox - no spawn, no approval event #9463 Windows Desktop shell 调用永久挂起（workspace-write 沙箱路径；本案全程无沙箱也复现，根因指向 start 请求竞态本身）
• Windows 沙箱下 pwsh 子进程启动即死 #8535 / 【Bug】Windows 10 上 workspace-write 沙箱模式下 pwsh 工具 100% 崩溃（0xC0000142） #9467（pwsh 启动即死 / 0xC0000142，是崩溃不是静默死锁）

[argszero]

Your forensic evidence is solid, and there is an in-tree half to it that explains why the wedge is survivable at all. Two independent reasons, both source-anchored.

1. A tools/execute timeout wrapper already ships — and it is cooperative.

@deepseek-ai/dsh-tool-call-timeout-policy (packages/guard/timeout-policy/src/index.ts) is mounted by default (packages/bundle/base/cordis.patch.yml, id timeout-policy). Its whole body is:

using d = deadline(exec.signal, timeoutMs, TOOL_TIMEOUT)
exec.signal = d.signal
try {
  const result = await next()                                   // ← awaits the body UNCONDITIONALLY
  if (timeoutOf(d.signal, TOOL_TIMEOUT) !== undefined) return toolTimeoutResult(timeoutMs)
  return result
}

It arms a deadline but never races it. Its own module doc states the design: "maps its own expiry to TOOL_TIMEOUT without racing or abandoning the tool promise". When the body never settles — your case exactly: runner alive, IPC connected, start frame lost — the timer aborts a signal nobody is reading and the await next() never returns. The timeoutMs contract on the tool definition is explicit that this is cooperative: declaring it "asserts this tool forwards exec.signal to a cooperative implementation that can reach quiescence when the signal aborts" (packages/core/tools/src/index.ts). A lost start frame breaks that assertion one layer below the tool.

2. It only arms when the tool declares a numeric budget — and none does.

The same wrapper starts with const timeoutMs = ctx.tools.get(exec.name, exec.agent)?.timeoutMs, and the design note is explicit: "The default behavior is conservative: a tool that declares no timeoutMs receives no TOOL_TIMEOUT deadline from the plugin" (.agents/notes/implemented/architecture/2026-07-07-tool-call-timeout-policy.md). Grepping packages/*/*/src for a definition-level numeric budget (timeoutMs: <number>) returns zero hits; the timeoutMs you can see in the bash/pwsh schemas is the model-supplied per-call argument the executor applies around its own child, which is a different knob — it cannot bound a call whose executor never returns.

So for a wedged call the guard is inert twice over: it was never armed, and even if it were, it does not race.

3. That is why your two proposed fixes are complementary, and the second one is plugin-reachable.

• runner.js start timeout — fixes the root (no more wedged runners). Core-side, and worth having.
• A non-cooperative bound above the tool — fixes the class: any body that never settles. This is the one that also covers your two "dispatch lost, no runner forked" cases, where a runner-side timeout has nothing to time out.

That bound does not need a core change — the extension point is documented. From the same note:

A listener receives (exec, next): it calls next() to delegate to dispatch (returning its result, optionally wrapped) or returns a replacement result to short-circuit dispatch.

tools/execute is that waterfall, its base next() is the dispatch thunk, and a returned result is normalized (normalizeDispatchResult, packages/core/tools/src/index.ts), so returning { isError: true, content, error } is accepted as the tool's result. A wrapper that races next() against its own ceiling and substitutes a structured error on expiry ends the hang even when the body ignores every signal — and the still-pending body promise settles into nothing.

4. Your item 3 is observable from outside too. sessionStats.pendingCalls is a session projection (packages/session/session-stats/src/projection.ts); it stores the dispatch timestamp per callId and is readable through ctx.sessionProjections from any plugin, so an out-of-tree detector needs no core hook either.

5. Honest limit. Ending the hang does not make the child go away: a body that ignores its signal keeps running after its result has been synthesized, so it still needs reaping — your 3-minute zombie script is exactly the right companion. If instead the signal is honoured, aborting it lets the body win the race on its own terms (toolAbortedResult), which is preferable when it is available.

Also: your "not sandbox-related, reproduces with no sandbox at all" point is worth keeping prominent — it separates this from #9463, whose hang does route through the sandbox path.

I have this non-cooperative wrapper drafted as an out-of-tree plugin; I will post the package link here once it is published, since the failure mode as reported has no way to end itself today.

[argszero]

A plugin now covers this seam — @argszero/cordis-plugin-tool-deadline-guard 0.2.0

Following the analysis above, I packaged the fix as a mount rather than a patch, because the wedging phase is exactly what the public tools/pre-execute waterfall exists for.

The gap, once more: ToolDefinition.timeoutMs bounds the body, and the core enforcer is a tools/execute wrapper — so the tools/pre-execute waterfall always completes before the policy is ever reached. A listener there that awaits unbounded work (here: the deliverable recorder's git checkpoint queue) stalls every tool call in the session, with no timer anywhere in the tree; a deadline mounted on tools/execute is structurally unable to see it, because that waterfall is never entered. That is why the pending call names the tool while the wedge is somewhere else.

What the mount does on that seam:

• registers tools/pre-execute with { prepend: true }, so its race encloses whichever listeners are already mounted (both orders are exercised by the suite, because only the "mounted after the wedge" one can fail);
• races the remaining phase against preExecuteTimeoutMs (default: defaultTimeoutMs);
• on expiry returns deny under its own code, TOOL_PRE_EXECUTE_DEADLINE_EXCEEDED, with the model-visible message Error: tool call to "<name>" was not dispatched: the pre-execute phase exceeded the <budget>ms deadline supplied by the tool-deadline-guard mount.

The code is deliberately not the body arm's TOOL_DEADLINE_EXCEEDED: this one says the body never ran, so nothing the call would have done has happened and the call can be treated as pure — which the body arm's code cannot say, because there the body did run and did not finish.

Two limits worth naming, both asserted rather than described:

• applyTo: 'undeclared' does not apply to this arm. That field exists to stop this mount racing the core policy over one body budget; a tool that declares timeoutMs still has an unbounded pre-dispatch phase, so it is bounded here like any other. exempt does apply, and preExecute: false turns the arm off.
• The wedged phase is abandoned, not cancelled — nothing can cancel same-process code, so it keeps running while the model is told the call never happened. What changes is that the call stops being the thing that never ends. A rejection arriving after the denial is captured into a value, so it cannot surface as an unhandled rejection in the host process.

The mount also supplies the original half (the body budget for tools that declare no timeoutMs), so one row covers both phases:

npm install @argszero/cordis-plugin-tool-deadline-guard

- insert:
    - id: tool-deadline-guard
      name: '@argszero/cordis-plugin-tool-deadline-guard'

Verified against the versions in this report rather than only its own build: the suite runs on @deepseek-ai/dsh-tools 0.1.7-rc.2 (+ cordis 4.0.4) and 0.2.1-alpha.2 (+ cordis 4.0.5-alpha.1) as well, 26/26 on each; 32 tests, 18 mutation arms, 0 survivors (each arm breaks one claim in the built artifact and the suite must go red).

One caveat for anyone who already tried 0.1.0 of this package: its peer range admitted 9 releases under npm's prerelease reading and 15 under pnpm's, the divergence being exactly 0.1.7-alpha.1 … 0.2.0-rc.2 — i.e. it excluded the line you are running. 0.2.0 rewrites both peer ranges as one explicit segment per release line, so npm and pnpm admit the same set.

Source and full notes: https://github.com/argszero/cordis-plugin-tool-deadline-guard