沙箱与审批：auto / full-auto / never
三种沙箱模式怎么选、审批卡的结构、fail-closed 设计原理、与权限边界的关系——安全策略不是「信任模型」而是「可恢复的失败」。
约 8 分钟读完
读完这篇你会
- 理解 DSH 沙箱的三种工作模式（auto / full-auto / never）
- 看懂审批请求在 UI 上是如何呈现的
- 选对模式匹配你的工作流（开发调试 vs 长任务无人值守 vs 严格审查）
适用版本
Compatible with: dsh 0.1.1-rc.2（基于官方 apps/cli/README + docs/user/guide/ 整理）
三种沙箱模式
DSH 的命令执行永远走沙箱。profile 配置里 sandbox.mode 决定默认行为：
| 模式 | 触发条件 | UI 表现 | 适用 |
|---|---|---|---|
auto | 工具调用命中「可推断安全」规则时自动放行，否则弹审批卡 | 偶尔弹卡 | 普通用户日常 |
full-auto | 全部放行，无任何弹卡 | 完全静默 | 长任务无人值守 / CI |
never | 所有工具调用都弹审批卡 | 每次都卡 | 严格审查 / 学习 |
模式可以在 profile 文件里设默认值，也可以在会话内临时切换（Web GUI 顶部「Sandbox」下拉）。
审批卡的结构
当命令需要人工批准时，UI 会渲染一张卡片，包含：
- 工具名 + 调用参数（如
bash("curl -I https://api.example.com")） - 文件 / 网络 / 进程影响范围推断
- 「Allow once」「Allow for session」「Deny」三个按钮
- 关联 plugin 名（谁触发这次调用）
可参考 dsh-approve-for-me 的「approve-for-me / strict-review」两个 GUI 权限预设——前者让轻量模型代理审批，后者强制每步人工复核。
失败安全（fail-closed）
DSH 沙箱默认 fail-closed：审批决策失败、模型超时、解析异常 → 一律拒绝。这是为了防止「审批子系统挂了导致模型自由跑命令」的灾难场景。
实操含义：
- 不要把审批决策模型配置成超时很短（如 3 秒），网络抖动会让你无法用任何工具
- 审批子系统（轻量模型）不可用时，临时切到
never模式手动审查即可——不要试图「绕过」沙箱
与权限边界的关系
沙箱只管「这次调用要不要问」，不管「这个插件有没有权限做这事」。权限边界由 bundle 声明 + Cordis 服务注入决定。两者是正交的：
- 沙箱放行 + 插件有权限 → 命令执行
- 沙箱放行 + 插件无权限 → 报错（plugin doesn't have service X）
- 沙箱拒绝 + 插件有权限 → 弹卡被拒
- 沙箱拒绝 + 插件无权限 → 弹卡被拒（权限缺失无意义）
故障排查
- 「full-auto 不应该被批准的命令被跑」：多半是有插件 hook 了审批管线；查
dsh --profile X --dump-patches看哪些 patch 注入了approve服务 - 「never 模式卡死整个会话」：单条卡可以选「Allow for session」批一整类相似命令
- 「auto 模式下明明安全的命令也被卡」：放宽 profile 里的规则集；具体规则名见
cordis.services.config.sandbox.rules
FAQ
沙箱能识别 npm install 吗？
能。auto 模式默认把 npm install 归为「可推断安全」（仅修改项目 node_modules + package.json），无锁文件时会升级为「需审查」。
沙箱能拦截 curl 吗？
能且默认拦截。full-auto 下 curl 也需走白名单（可由用户配置），这是 DSH 默认比传统 agent 严格的地方。