DSH（DeepSeek Harness）允许智能体在沙箱环境中执行 Shell 命令。传统的安全策略往往基于命令名称（如 rm 或 cat）来判断危险程度，这种方式容易导致误判，或者让看似无害的命令由于名字被阻止。dsh-allow 插件改变了这一逻辑，它分析命令实际需要访问的文件系统路径和操作能力，以此决定是否授予权限。
是什么¶
dsh-allow 是一个为 DSH 提供的文件系统权限层插件，由开发者 DWJZ 维护。它的核心作用是将权限控制从“按命令名”转移到“按路径和能力”。
该插件在 tools/pre-execute 钩子中介入，解析命令的文件系统效果，结合预定义的规则生成 Seatbelt 配置文件。这意味着，沙箱内的子进程、命令行中未显示的内联代码，以及通过该命令启动的程序，都会被强制遵守这些权限规则。
核心功能¶
- 路径级权限控制：支持对特定路径进行
read（读取/列表）、write（修改）、create（创建）、delete（删除）、execute（执行）五种能力的细粒度控制。 - 策略模式：支持
deny（拒绝）、allow once（单次允许）、always allow（始终允许）三种策略。 - 工具操作规则：针对请求更宽泛进程权限的管理工具（如
plugin_manager）制定规则。 - Seatbelt 强制执行：将策略编译为 macOS 的 Seatbelt 配置文件，在沙箱入口处强制执行。
- 审批界面：提供 Approvals Tab 用于人工审批。
使用示例¶
权限的授予基于路径和操作类型，而非命令名称。以下是一些典型的判断逻辑：
| 命令操作 | 结果 | 说明 |
|---|---|---|
cat README.md |
allow | 读取工作区内的文件 |
cat ~/.ssh/id_ed25519 |
refused | 用户数据被隔离，不可读取 |
echo x > out.md |
allow | 在工作区内创建文件 |
rm -rf build |
prompt | 工作区内删除操作需要审批 |
gh pr list |
prompt | 执行未在规则中授权的二进制文件 |
echo x > ~/.dsh/dsh-allow.json |
refused | 权限存储文件受硬保护，不可写入 |
配置与注意事项¶
- 权限存储保护：权限存储文件（通常位于
$DSH_HOME/dsh-allow.json）和审计日志是“硬保护”的。无论是用户规则还是智能体，都无法通过文件工具修改这些文件。 - 工作区隔离：插件不会读取工作区内的
.dsh-allow.json，防止仓库代码自行提升权限。 - 系统路径保护：平台受保护路径（如
/System、/bin、/dev等）对任何写操作（write、create、delete）都是拒绝的，无论用户规则如何配置。 - 许可证：MIT License。
目前官方未提供特定的安装命令，可通过 SkillHub 目录 或 GitHub 仓库 获取。
短结尾¶
dsh-allow 通过将安全策略建立在文件系统路径和操作能力之上，替代了粗糙的命令名过滤机制。配合 Seatbelt 的强制执行，它为 DSH 智能体提供了更可靠的沙箱隔离能力。
