前言¶
在 DeepSeek Harness（DSH）里让智能体跑 Shell 时，常见一类失败：模型发出 git commit 却没带 -m，或执行 npm run dev、python3 后没有后续参数。命令在等键盘输入，而无人输入；工具往往等到超时，这一轮几乎学不到有效反馈，下一轮还可能再试同样会挂起的调用。
手工在提示词里强调「不要交互式命令」能缓解一部分，但无法覆盖管道、&& 链、包装命令等组合。下面介绍社区插件 dsh-block-hanging-commands（维护者 acus9345），它在命令真正执行前做静态检查，对会等待输入或长期不退出的调用直接拒绝，并把原因与可替代写法返回给模型。
这是什么¶
dsh-block-hanging-commands 是 DeepSeek Harness 的插件，分类为 admin-security。它在 tools/pre-execute 阶段读取即将执行的 Shell 命令，对匹配规则的调用返回 deny 及说明文字，不改写命令、不启动 Shell；模型可在同一步根据提示改用非交互方式。
源码与说明见 GitHub 仓库，社区目录页：skillhub.cn/plugins/acus9345/dsh-block-hanging-commands。该目录为独立社区站点，与 DeepSeek / 幻方无官方从属关系。
核心功能¶
规则覆盖范围¶
插件对命令做词法级解析（不 spawn Shell），并识别常见包装（sudo、env、nohup、npx、bash -c 等）以及管道、&&、heredoc、重定向。README 中列出的规则与示例如下。
| 规则 | 典型命令 | 建议替代 |
|---|---|---|
editor |
vim、nano、code --wait |
使用编辑工具或 sed -i |
git-editor |
无 -m 的 git commit、git tag -a |
git commit -m "..." 或 --no-edit |
git-interactive |
git rebase -i、git add -p |
非交互 rebase / git add <path> |
repl |
python、node、psql mydb |
-c "..."、脚本文件或 heredoc |
server |
npm run dev、vite、next dev |
run_in_background: true 或 timeout |
watch |
jest --watch、tsc -w |
去掉 watch，单次执行 |
follow |
tail -f、kubectl logs -f |
tail -n 200、--since 等 |
remote-shell |
无远程命令的 ssh host |
附带远程命令；-o BatchMode=yes |
container-tty |
docker run -it、kubectl exec -it |
去掉 -it |
tui |
htop、lazygit |
批处理形式（如 top -bn1） |
prompt / login |
无 -y 的 npm init、gh auth login |
非交互标志或向用户确认 |
pager、tty-prompt |
less、sudo 要密码 |
仅在 PTY Shell 下启用相关规则 |
拦截时，模型会收到类似下面的反馈（摘自 README）：
dsh-block-hanging-commands stopped `git commit` before it ran, because `git commit`
without a message opens an editor, so the tool call would just sit there until it timed out.
Instead: pass the message: `git commit -m "<message>"` (or `--no-edit` when amending).
(rule: git-editor)
放行与例外¶
为降低误拦，以下情况会放行：psql -c "select 1"、node script.js、git commit -F msg.txt、ssh host uptime、--help / --version 等。echo q | python3、python3 < script.py 因输入已就绪而不拦。timeout 30 npm run dev、带 run_in_background: true 的 dev server，或 Shell 工具自身 timeoutMs 能界定时长的调用也会放行。Windows 上通过 PowerShell（pwsh）执行时，插件同样处理 npm.cmd、路径形式的可执行文件等。
安装与启用¶
DSH 按 profile 维护插件列表：web（dsh web 浏览器 UI）、headless（脚本与 CI）、acp（编辑器集成）。在你会用到的每个 profile 上单独安装。
以 web profile 为例：
dsh plugin --profile web add dsh-block-hanging-commands
插件自带 patch 层，安装后即生效，无需额外开关。卸载：
dsh plugin --profile web remove dsh-block-hanging-commands
配置¶
可在 DSH 侧边栏 Plugins 中打开 dsh-block-hanging-commands，修改后 Save，下一次工具调用即生效，无需重启。
也可在 ~/.dsh/profiles/<profile>/cordis.patch.yml，或全局 ~/.dsh/cordis.patch.yml 中写入：
- id: block-hanging-commands
config:
mode: deny # 或 ask：弹出确认而非直接拒绝
tools: [bash, pwsh] # 要检查的 Shell 工具名（Windows 为 pwsh）
pty: false # Shell 是否在 PTY 上运行（如 dsh-tool-bash-persistent）
disabledRules: [] # 例如 [server] 以允许启动 dev server
allowPatterns: [] # 正则白名单，如 ['^make serve$']
未填写的键保持默认。pty 为 false 时，less、sudo 等依赖终端的规则不会启用，以避免在无 PTY 环境下的误报。
适用场景与注意¶
适合在 DSH 中频繁让智能体执行 Shell、又希望减少「整轮挂死」的团队或个人。插件以当前 dsh 进程权限 运行，安装前建议阅读 源码 与 MIT 许可证，确认行为符合你的安全策略。
若你确实需要模型启动 dev server 或 watch 模式，可通过 disabledRules 或 allowPatterns 放宽；mode: ask 则在拦截前走人工确认。
结尾¶
dsh-block-hanging-commands 把「会挂起的 Shell」从执行阶段前移到可解释的拒绝与替代建议，减轻超时空转。更多信息见 社区目录页 与 GitHub。
