常见问题（FAQ）

August 19, 2026 · View on GitHub

会不会让我的 DSH 打不开？

不会。插件采用 fail-soft 设计：注册/加载任一环节出错时仅降级记日志，不影响 DSH 启动。

它是不是和 DSH 自带的沙箱/审批重复？

部分重复，但不完全。DSH 自带 dsh-sandbox-policy（工作区外要审批）+ dsh-user-approval（确认门）——在配置正确的前提下，那才是第一道、也是更强的一道防线。但现实里沙箱常常是宽开的（曾实测：一条 Remove-Item -Recurse -Force 没有任何内置机制拦住）。本插件补的是：

  • dsh 没有的恢复层：回收站/undo、组合快照/回滚、删除审计、重启前体检；
  • 问人层：重要的删改必须先经过用户审批（safety_ask → dsh-safety allow）；
  • 宽开沙箱下的兜底拦截。

最佳实践：先把 DSH 沙箱/审批配好，再用本插件做恢复层与问人层。

模型想删除/改写重要文件时，正确流程是什么？

  1. 模型调用被守卫拦截，收到教育式拒绝（是什么/为什么/后果/正路）；
  2. 模型调用 safety_ask，附上因果（what / why / consequence / alternative），得到 request id；
  3. 模型把 id 告诉你；
  4. 你执行 dsh-safety allow <id>（或直接 dsh-safety delete <path> --force）；
  5. 模型重试原调用 → 守卫放行一次（该审批即被消费）。

为什么 force:true 不够了？

因为模型能自己传 force:true——模型可自设的标志不是用户确认，那等于没有确认门。所以现在 safe_delete 的 force:true 只是标记，删除 confirm/protected 目标前必须存在已由用户批准的审批请求。CLI 侧的 dsh-safety delete --force 是例外：CLI 用户就是人类本人，--force 即真实审批。

如何删除受保护路径上的文件？

CLI 侧（你是人类）：

dsh-safety delete <path> --force    # 先授予所需审批，再移入回收站（可撤销）

模型侧：让模型先 safety_ask 创建请求，你再 dsh-safety allow <id>。无论哪种方式，删除只进回收站、永不真正删除，可随时 undo。

模型被拦之后一直"换别的办法"重试，怎么办？

这正是守卫要阻止的行为：systemPrompt 已明确"被拦就停、不许换工具/换路径/编码绕过"，且同一目标反复被拦会升级为 STOP 警告。如果模型仍在纠缠，直接回复它：调用 safety_ask 说明因果并等待批准，或放弃该操作。

为什么递归删除默认在任何路径都无条件拒绝？

目录递归删除（rm -rf、Remove-Item -Recurse）的破坏半径最大、意图最难判断，且正是那次真实事故的直接手法。策略为默认拒绝、显式放行——需要删除时走 safe_delete 进回收站（可撤销）。mode: cooperative 下人类可授予一次性通用递归审批放行自由路径的递归删除（dsh-safety allow --path … --recursive）。

strict 和 cooperative 有什么区别？

  • strict（默认）：递归 shell 删除永不可批准，目录树删除唯一通道是 safe_delete（回收站、可撤销）——最安全；
  • cooperative：人类可授予一次性审批放行自由路径的递归 shell 删除——更灵活，但删除是永久的、不进回收站，只在你明确信任该操作时使用。

DSH 打不开了，我还能用这个吗？

能。CLI（dsh-safety）完全不依赖 DSH，直接读写 $DSH_HOME/.dsh-safety 状态：

dsh-safety check                      # 找乱码/JSON/重复 id / find mojibake/JSON/duplicate ids
dsh-safety status                     # 看可用快照 / list available snapshots
dsh-safety restore <id> --confirm     # 回滚 / roll back

模型用 run_code 执行任意代码，会不会绕过？

guard 会扫描 run_code 的代码体文本（fs.rmSync/shutil.rmtree/require('fs').rmSync + 保护标记），直白写法会被拦。但文本扫描挡不住动态拼接/混淆——这是根本边界：run_code 是任意代码执行，真正隔离它的只有 DSH 沙箱，插件只是增加一层难度。

会不会吃满我的磁盘？

不会。回收站和快照都有保留上限（keepTrash 默认 200、keepSnapshots 默认 10），每次删除/快照会自动裁剪。

我有多个 profile，能用吗？

能。buildPolicy 自动扫描 $DSH_HOME/profiles/* 下全部 profile，不需要逐个配置。

我在用 OCL（deepseek-harness 的 fork），能用吗？

本插件面向 DSH（$DSH_HOME、@deepseek-ai/*）。OCL 用的是 OCL_HOME 和 @ocl/*，需要一个小适配层（homeIsConfirm 等配置已预留）。社区版暂未内置 OCL 适配。

它和 dsh plugin 安装流程冲突吗？

不冲突——本插件只走官方流程：dsh plugin --profile <name> add <包名>（或本地 link:）。包会被自动 reconcile 进该 profile 的 dsh.profile.bundles，装进 $DSH_HOME/profiles/<name>/node_modules/，不需要任何手工配置，也没有"个人聚合包"这种额外约定。

快照里会不会存到我的密钥？

不会。settings.yaml、.credentials.yaml 默认被排除（snapshotExclude 可配置）。但请勿把 $DSH_HOME/.dsh-safety/ 目录本身推上任何公开仓库。

之前设置里的「安全中心」面板哪去了？

按用户要求已移除（连同其 /safety/api 路由与浏览器半区 lib/client.js）。管理/审批/审计全部走模型侧工具与独立 CLI（safety_ask、dsh-safety allow/approvals/revoke、safety_journal/safety_status），功能不受影响。

模型会不会在 safety_ask 里撒谎（把危险操作说成无害）？

会——what/why/consequence/alternative 四个字段由模型单方填写，系统无法核验其真实性。为此每个审批请求额外携带系统按真实路径分类计算的后果（systemNote）：dsh-safety approvals 把 [system] 判定与 (model: …) 自述分开显示，批准时以系统判定为准。但这只解决"信息呈现"——如果你不看就批（橡皮图章），任何提示都拦不住；所以请至少在批准前扫一眼 [system] 那栏。