阻塞调用拦截 baldovinmarques391-design/dsh-ban-wait

dsh-ban-wait

一个 Host 插件，拒绝会让 DSH 智能体循环停摆的工具参数。

它之所以存在，是因为 shell 命令超时并不是上限。pwsh-sandbox 的 timeoutMs: 1000 会把长命令提升为后台任务，但模型可以在调用时自己传 timeoutMs: 180000，执行器会照办，直到 maxTimeoutMs（默认 600000 ms）为止——单次工具调用里就能跑三分钟。同一类漏洞还有 job_output { wait: true }，只受 10 分钟默认值约束。这个插件把「没有哪次调用能让循环停摆」变成工具注册表的属性，而不是模型自觉性的属性。

文件

| 文件 | 作用 |
| index.js | 插件本体：策略 + 全局 ctx.tools.guard() |
| check.mjs | 策略的离线自检（30 条断言，不启动 DSH 进程） |
| bundle-check.mjs | 安装前检查：用 harness 自带的补丁加载器，重放插件页面所检查的内容 |
| cordis.patch.yml | bundle 的补丁：插入 Host 平面那一行 |
| package.json | dsh.bundle.patch → cordis.patch.yml；无依赖 |

策略

| 配置字段 | 默认值 | 含义 |
| maxBlockingMs | 1000 | 模型提供的任何单次调用阻塞提示的上限 |
| denyWaitTools | ["job_output"] | wait: true 会被拒绝的工具 |
| timeoutHintTools | ["pwsh", "bash"] | timeoutMs / timeout_ms 会对照 maxBlockingMs 检查的工具 |
| requireBackgroundTools | [] | 必须以 run_in_background: true 调用的工具 |

拒绝会返回一条 Error: … 工具结果，写明禁令、撇清后台任务的责任，并说明如何重新发起调用，让模型一步就能恢复。配置值不可用时记录日志并替换为默认值，而不是抛错：这里的一个笔误不能导致实例启动失败。

安装

通过插件页面安装——这是唯一能让插件带着自己的开关出现在清单里的渠道：

1. 添加插件 → 粘贴项目的绝对目录（你刚克隆下来的 checkout）。本地目录会在任何 npm 规格解析之前由 isAbsolute() 识别，从不访问 registry，所以那个对话框里的 registry 选择器无关紧要。
2. 管理器读取 package.json，要求有 name 和 dsh.bundle，把依赖加到配置档，然后自动协调 dsh.profile.bundles（「新的 bundle 依赖会自动激活」）。插件随后出现在已安装下，带一个开关。
3. 如果结果提示需要重启，就重启实例：新的 Host 模块代不会加载进正在运行的进程。

不要再往配置档补丁里给这个插件加一行原始 loader。bundle 的 cordis.patch.yml 会插入行 id ban-wait，两行共用这个 id 会让按 id 定位的补丁——开关、任何覆盖——只命中其中一行。

配套配置，没有它，守卫就是模型和三分钟调用之间唯一的屏障：

- id: pwsh-sandbox
name: "@deepseek-ai/dsh-pwsh-sandbox"
config:
timeoutMs: 1000 # default for a command
maxTimeoutMs: 1000 # ceiling for the model's timeoutMs argument — the line that matters maxOutputBytes: 10000

验证

the policy itself (30 assertions)
node check.mjs

the package the plugin page will inspect: path, package.json, name, dsh.bundle,
files coverage, and a real parse of cordis.patch.yml by the harness loader
node bundle-check.mjs

这两步都不能证明插件已激活——激活发生在配置档挂载 bundle 层的时候，插件页面会在安装结果里报告。

实时探测（每次都会返回拒绝，而不是执行）：

job_output { job_id: "pwsh-1", wait: true } → Error: … (ban-wait): job_output was called with wait: true
pwsh { command: "ok", timeoutMs: 180000 } → Error: … caps how long one tool call may hold the agent loop at 1000 ms
pwsh { command: "ok" } → runs normally
workflow { script: "return 1" } → runs synchronously (not banned by default)

已在实例 3080 上验证：两次拒绝都会触发，普通调用和非阻塞的任务读取行为与之前完全一致，这一行能实时挂载和卸载——全程都不需要重启。

边界

- 守卫看的是参数，不是时长。某个工具没有阻塞参数、只是跑得久，它就管不到；这种情况要靠 requireBackgroundTools，而 shell 的 maxTimeoutMs 上限已经替命令处理了。
- ask_user_question 故意永不封禁：阻塞等人正是它的功能。
- workflow 和同步的 subagent 默认不封禁。它们在调用内部做实际工作，改成后台运行会改变结果的消费方式。想要这种取舍时，按工具逐个启用：
requireBackgroundTools: [workflow, subagent]

已被取代

这个插件最初只是一条封禁规则，仅拒绝 job_output { wait: true }；那个早期版本已经并入这里发布的策略，所以没有需要单独安装的东西了。