dsh-limit-timeout

dsh-limit-timeout

限制 DSH agent 单次工具调用可以让调用方等待多久: 全局默认上限放在设置界面, 模型需要更长等待时可以在会话中向你申请提升.

它解决什么

bash 的 timeoutMs, job_output 的 timeout_ms 这类参数由模型自己填写, 部署 侧原本只有一个很宽的工具配置兜底. 本插件在调用真正执行前检查这些参数:

• 超过本会话上限的调用被拒绝, 拒绝理由写清当前上限, 并给出三条替代做法: 降低等待 时间, 改用后台执行 (run_in_background: true + job_output), 或者调用 request_wait_extension 向你申请提升.
• 申请走 DSH 原生审批通道, 由你决定是否批准; 批准后只对当前进程内的这个会话生效.

安装

Web 端装进 web profile:

dsh plugin --profile web add azazo1/dsh-limit-timeout

装好后重启 dsh web, 让 profile 重新扫描 Client 元数据并刷新页面.

桌面端装进 desktop profile. 它由 Electron 应用独占管理, dsh plugin 会拒绝 --profile desktop, 所以要用应用内的插件管理器: 在插件页的安装入口填上面命令里对应的包名或本地目录. 装上后重启应用, 窗口刷新一次.

引擎版本线要求 @deepseek-ai/dsh-* 不低于 0.2.0-rc.1, 且仍在 0.2.x 上 (peerDependencies 与 devDependencies 都写作 >=0.2.0-rc.1 <0.3.0). 更早的引擎线装不上这个版本.

web 与 desktop 两个 profile 跑的是同一套 Web 应用, 桌面端只是多起一个 Host 子进程并给 <html> 打上平台标记, 所以同一份包在两边通用, 不需要分别构建.

设置

设置界面只有一个入口: Settings > 等待上限 独立页, 包含全部字段, 其中全局默认等待 上限是日常唯一需要改的值.

这一页是草稿式编辑: 改动不会立即生效, 有未保存改动时才出现 "保存" 与 "放弃更改" 按钮; 保存是一次原子写入, 放弃更改立即还原成当前生效值.

两个时长字段接受 120000, 500ms, 90s, 2m, 1h 这类写法, 省略单位按毫秒, 允许小数; 未编辑, 保存后与放弃更改后都会还原成合适的单位写法 (2m, 30m, 90s, 1500ms). 默认上限不能高于硬天花板, 否则保存被拒绝.

运行时行为

• 拦截发生在 tools/pre-execute: 放行时继续交给下游策略 (权限, 沙箱) 判断, 超限时 直接短路成错误结果, 调用不会真正执行.
• 工具参数在进入策略管线前已经记录并呈现, 所以插件只能拒绝, 不能改写参数; 这也是 不做静默钳制的原因.
• 提升按会话对象记录在进程内存里: 新会话, 会话恢复与进程重启都回到全局默认值.
• 每次拒绝都会以 info 级别记入 Host 日志, 包含工具名, 调用 id, 当前上限与是否已提升.
• "屏蔽重复调用提醒" 在 agent/pre-step 过滤 repeat-tool-reminder 的注入消息: 只改 变模型看到的内容, 会话日志与历史回放不受影响, 被过滤的条数记入 debug 日志.

边界

• 只覆盖模型可控的等待参数 (timeoutMs, timeout_ms). 工具自身的部署超时 (例如 web_fetch 的 fetchTimeoutMs) 不受影响.
• job_output 只写 wait: true 而不写 timeout_ms 时, 等待时长由 dsh-tool-jobs 自己的 waitTimeoutMs 决定, 默认配置下不受本插件约束; 需要严格限制就打开 "要求显式声明等待时长".
• 提升不写入会话日志, 因此不可回放, 也不能跨进程保留.

开发

just install
just typecheck
just build
just test
just verify

src/ 是 TypeScript 源码, lib/ 是构建产物 (随包提交). Host 半区注册设置, 拦截器, 申请工具与运行时提示; Client 半区注册设置界面入口.