先看规则，再请 AI 判断，最后按你选择的模式处理。

例如，在默认的日常模式下，如果这些 Bash 命令触发审批：

• git status：常见只读操作，内置规则直接放行。
• npm publish、git push：发布操作属于红条，必须你本人确认；无人值守时直接拒绝（写死的策略，没有"无人值守就放行"的开关——要在无人值守时放开权限请改宿主的权限档位）。
• rm -rf ./dist、Remove-Item -Recurse build：递归删除一律交你确认——工作区是沙箱的写边界，不是备份，删掉的东西不受权限档位保护。rm -r 也算，rm -rvf 这类打包写法同样命中（判定在 argv 上做，靠拼写绕不过去）；rm -rf /、rm -rf ~/Documents 这类越界形态则是直接拒绝。
• git clean -fdx、git reset --hard、git branch -D、docker system prune -af --volumes、kubectl delete ns、wipefs -a：整体状态删除直接拒绝——未提交的工作、分支提交、卷、对象存储前缀在别处没有副本，没有一次授权能把它们找回来。日常形态不被牵连：git branch -d（只删已合并分支）、git restore --staged（只动索引）、kubectl delete pod（重启 Pod 就是删它）交给 AI 判，wipefs -n（dry run）直接放行。
• 其他没被规则覆盖的操作：交给 AI 评估——它同时给出风险、它建议的处理方式和用户授权强度，最终放行与否由程序按规则算；证据不足时它可以要求读取工作区内的脚本再判断。

你可以自行调整规则。带有重定向、串联执行等复杂写法的命令，会做额外检查，不会仅凭开头看起来是只读命令就按规则放行。

想了解具体判断方式，见 决策链与规则语法。

使用注意

• 保留沙箱。 支持 workspace-write 和 read-only；danger-full-access 不产生这类审批请求，插件不会介入。
• 同一个 profile 只启用一个自动审批插件。 多个审批插件可能互相干扰。
• AI 可能判断错误。 自动审批不能保证所有操作安全，请按任务需要配置权限与策略。具体边界见 安全说明。

常见问题

装了以后没变化？

确认已重启 dsh web 进程，而不只是刷新页面。再检查会话权限是否为 workspace-write 或 read-only，并用 /approval-mode 确认插件没有处于人工模式。

为什么还是经常弹窗？

可能是某个操作需要你确认，也可能是判定模型不可用。先检查设置里的模型配置；仍有问题时，可查看 ~/.dsh/logs/approval.jsonl 中的决策记录，或参阅 排查文档。

如何卸载？

dsh plugin --profile web remove dsh-codex-approval