DeepSeek Harness 工具调用永久卡死：Windows runner 挂起与沙箱拒绝不提示

Windows 上的沙箱问题有两种极端表现：一种是「什么都说了但什么都没跑」——工具调用永久卡在执行中，界面一直转，等两小时也不返回；另一种是「跑了也被拒，但没人告诉模型」，于是模型看不到任何拒绝标记，自己换个写法绕过沙箱。 前者来自沙箱子进程的启动握手没有任何超时：runner 已经 fork、IPC 也连上了，但那条 start 帧丢在管道里，两边就永远互等（社区核对源码确认 runner.js 整个文件里 setTimeout 出现 0 次）；后者来自拒绝分类的匹配面太窄：沙箱只对 stderr 匹配拒绝签名，而某些运行时把 EACCES 打在 stdout，于是 sandbox.denied 永远不会被置位，[sandbox: file access denied …] 标记与升级提示都不会出现（#9515、#9497）。本文分别给出「怎么判定」与「怎么修／怎么绕」，两条都能在不重启整个 DSH 的前提下处理完。

DeepSeek Harness 工具调用永久卡死：start 帧丢失 + 三层都不设超时

一句话结论：这类卡死的本质是「启动握手丢帧」，而不是命令太慢——因为从父进程到 runner 再到工具层，没有任何一层给它上过超时。 症状特征是：GUI 一直显示执行中（最长两小时以上），会话里既没有 tool/result 也没有错误，重启应用才恢复（#9515）。

DSH插件 机制：为什么三层超时都兜不住

据社区逐行核对源码，缺超时的地方有三处，层层递进：

1. runner 自身无超时：dsh-subprocess-local/lib/runner.js 在等待 IPC 的 start 消息时进入等待，全文件没有任何 setTimeout，start 帧丢失即双方永久互等；
2. 会话统计无看门狗：sessionStats.pendingCalls 只是计数，不参与任何超时判定；
3. 工具层是协作式超时：tools/execute 的超时包装只 abort exec.signal 后继续 await next()，不能 race 掉一个永不 settle 的 promise；而且它只在工具声明了 timeoutMs 时才武装，而现场没有任何工具声明过（#9515）。

把这三条连起来看就很清楚了：「丢帧」是小概率事件，但一旦发生，整条链上没有任何一层会把它掐断——所以它会一直挂着，直到你重启。

DeepSeek Harness 三步判定：这是僵尸 runner，不是「模型在思考」

判据是三件事同时成立——进程活着、几乎不耗 CPU、没有任何子进程。三步：

1. 看 runner 进程是否还在。 在非受限 PowerShell 里列出候选：

Get-Process node -ErrorAction SilentlyContinue |
  Where-Object { $_.Path -like "*dsh-subprocess-local*" } |
  Select-Object Id, ProcessName, StartTime, CPU

预期：能看到一个 StartTime 明显早于现在、且 CPU 数值很小的进程。

2. 看它有没有子进程。 执行：

$runner = <上一步拿到的 Id>
Get-CimInstance Win32_Process -Filter "ParentProcessId=$runner" | Select-Object ProcessId, CommandLine
#   → 预期无输出：runner 已起，但目标命令从未被启动

3. 看它是否「活着但不动」。 间隔 30 秒连续两次采样 CPU 值，若两次几乎相同且小于 1 秒，同时 StartTime 已超过 3 分钟，即可判定为僵尸 runner（#9515）。

对照确认：此时会话里应当没有该工具对应的 tool/result 事件——如果已经有结果，那就不是本族，去查别的方向（子进程在加载器阶段就启动失败、报 0xC0000142 的那种，见 DeepSeek Harness Windows 子进程报 0xC0000142）。

DSH插件 处置：杀僵尸 + 加非协作兜底

恢复很快，防复发要靠非协作超时。 两步：

1. 结束僵尸 runner（最快恢复手段）。 据讨论中实测，杀掉进程后约 2 秒即自愈，工具调用立刻返回，不需要重启 DSH：

Stop-Process -Id $runner -Force
#   → 预期：卡住的工具调用在约 2 秒内以失败返回，会话恢复可用

2. 装非协作的 deadline 兜底。 社区插件 @argszero/cordis-plugin-tool-deadline-guard 挂在 tools/pre-execute 上，用一个与底层 promise 无关的墙钟上界强制结束调用——这正是「协作式超时」缺的那层：

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

在 profile 的 patch 层挂载：

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

3. 验证： 重开后跑一条会超时的命令（例如 pwsh -Command "Start-Sleep 600"），预期在插件设定的墙钟上界内收到超时错误，而不是无限转圈。

边界提醒：本族与「沙箱路径挂起」是两回事——后者只在 workspace-write 下出现、切 danger-full-access 就正常；而僵尸 runner 在没有沙箱的场景里也能复现。所以先看「切完全权限是否恢复」这一条，能立刻分流（#9515）。

DeepSeek Harness 沙箱拒绝不提示：拒绝信息打在 stdout，被分类器漏掉了

一句话结论：沙箱确实拒绝了这次写入，但「拒绝」这件事只在一处被识别——stderr 上的签名匹配；当拒绝码出现在 stdout 时，标记与升级提示都不会渲染，模型看到的是「命令失败了」而不是「你被策略拦住了」。 后果比看起来严重：模型不知道这是策略边界，会改成别的写法绕过（讨论里举的例子是覆盖 XDG_CONFIG_HOME 把配置写到工作区内），于是「安全控制被默默消解」；同族里还有一类是失败被静默丢弃掉（管道 stdio 把输出丢成 0 字节、CIM 返回静默默认值等），见 DeepSeek Harness 沙箱命令全失败（#9497）。

DSH插件 机制：三个条件同时不满足，标记就不会出现

据社区核对源码，控制标记渲染的链路有三道门：

1. 分类只认 stderr：classifyDenial / matchesSignature 只对命令的 stderr 匹配 DENIAL_SIGNATURES；
2. 有些工具把拒绝码打在 stdout：例如某些运行时的 telemetry 把 EACCES 写进 stdout，stderr 只剩 launcher 的信息行，于是签名一条都匹配不上；
3. 渲染层还有额外门：标记与提示由 render 层产生，且 gated on result.sandbox?.denied；升级提示还需要 composition 提供非空的 escalationModes。而 DENIAL_SIGNATURES 是模块私有常量、未导出，插件无法直接复用它来补判（#9497）。

DeepSeek Harness 三步判定：这次失败到底是不是沙箱拒绝

1. 看路径是不是真的在工作区外。 检查失败命令里被写的目标路径，确认它不在当前工作区之内（工作区路径在 设置 → 工作区 里可见）。
2. 看退出码与结果文本。 预期是「退出码非 0」+「结果里没有 [sandbox: file access denied …] 标记」+「没有升级提示」。「确实被拒、但没有任何 sandbox 标记」就是本族的指纹（#9497）。
3. 手动验证拒绝发生在哪条流上。 在受限会话里执行：

pwsh -Command "echo probe > $env:USERPROFILE\probe-denied.txt"
#   预期：文件未创建、命令非 0 退出
#   把同样内容改成写工作区内路径，预期成功 —— 这条对照排除「命令写错」

DSH插件 处置：在 post-execute 上补标记

核心思路是不去改沙箱，而是在结果出来之后把 sandbox.denied 显式置真，让上层自己渲染标准标记。 三步：

1. 装社区插件 @argszero/dsh-stdout-denial-guard（它在 tools/post-execute 上设置 sandbox.denied = true，hint 通过 additionalContexts 下发）：

npm i @argszero/dsh-stdout-denial-guard

2. 在 profile 的 patch 层挂载：

- insert:
    - id: stdout-denial-guard
      name: '@argszero/dsh-stdout-denial-guard'

3. 验证：重开会话后再跑第 2 步那条被拒命令，预期结果里出现 [sandbox: file access denied …] 标记，且模型收到一句「这是策略拒绝、可申请升级」的提示而不再改道绕过。

一定要知道的边界：该插件只覆盖模型侧——它让模型知道「被拒了」，但不改变沙箱实际行为。而且它对 shell 命令行里拼出来的路径只做尽力识别，不能当作安全边界（#9497）。

DSH插件 排查注意事项

两条症状看起来无关，但都属于「沙箱行为没有被正确表达给上层」——一条是没超时，一条是没标记。判断顺序建议先分流、再深挖。 七条要点：

1. 先做一次分流：切 danger-full-access 后问题消失 → 偏向沙箱路径；不消失 → 偏向 runner/进程层（#9515）。
2. 卡死时不要急着重启 DSH：先按三步判定确认是僵尸 runner，杀那一个进程即可，重启会中断所有会话（#9515）。
3. 「runner 存活 ≥3 分钟 + CPU < 1 秒 + 无子进程」直接判定僵尸，不必等更久（#9515）。
4. 协作式超时不可靠：凡是「超时了也不返回」的现象，优先怀疑底层 promise 永不 settle，而不是超时值设得不够大（#9515）。
5. 2>&1 合并流救不了拒绝标记：拒绝码本来就不在 stderr 上，合并之后仍不是匹配目标（#9497）。
6. 看到模型「自作聪明换写法」时优先查标记：模型绕过沙箱往往是它没被告知被拒，而不是它在对抗策略（#9497）。
7. 修复状态如实：两条都未修——超时补丁与拒绝分类都还是社区插件形态，插件层也只能「兜底」（补 deadline、补标记），不能替核心修掉根因。

排查这类跨进程问题时，除了看进程状态，也值得把安装/卸载类操作集中到一个地方，减少变量。如果你希望插件的装卸、更新与系统日志都在一个面板里，与其在各处手敲命令，不如用 DSH Plugin Hub——它把插件装卸、更新确认、诊断与日志收在一起，能帮你先把「插件层」这个变量排掉。

来源：Discussion #9515、Discussion #9497。