zjuhbh/dsh-full-with-approval

dsh-full-with-approval

DeepSeek Harness (DSH) 的 profile 插件，新增第四个权限预设 full-with-approval：

- 全能力计算 —— 会话沙箱模式为 danger-full-access，进程不隔离：CUDA/GPU、设备、网络以及本机可运行的一切二进制都可用。
- 文件修改逐次审批 —— 该预设激活期间，每次 write/edit 若涉及
- 工作区外的文件（平台临时目录与配置的 scratch 目录除外），或
- 工作区内受保护文件（默认 .git/、.env），

都会在执行前向用户申请一次性授权。审批走的是沙箱升级重试所用的同一交互通道（ctx.approval，allowed-once）。拒绝/取消 ⇒ 工具失败，不写入任何内容；无可用审批通道时 fail-closed 拒绝。
- shell 修改逐次审批 —— bash/pwsh 命令若带有修改工作区外文件迹象（出现工作区外路径 + 写标记：重定向、chmod、rm、python、curl -o 等），也会先弹审批；明显只读的调用（cat、ls、grep、env 等且无写标记）与仅涉及工作区内相对路径的命令直接放行。静态启发式宁可多问：解释器（python/node）与命令替换中出现工作区外路径必问。bashGuard: false 可整体关闭该层；extraBashTokens 可追加"出现即问"的子串。

其余情况——工作区内普通文件写入、临时/scratch 文件、所有读取与一切命令执行——不受打扰。

原理

插件只是 DSH 现有扩展点上的薄薄一层，不改任何核心包：

1. cordis.patch.yml 的 full-with-approval 条目挂载本插件。
2. 同一 patch 按 id 覆盖 permission 预设表，加入第 4 档 full-with-approval = { sandbox: danger-full-access, approval: ask }。GUI 权限选择器与 /permission 命令都读这张表，新档位自动出现。
3. 插件监听工具注册表的 tools/pre-execute 瀑布（官方 allow / deny / ask before dispatch 钩子）。当会话有效预设为 full-with-approval 且调用是 write/edit、目标在工作区外或受保护时，返回 { kind: "ask", reason }；注册表通过 ctx.approval.request(...) 处理询问，仅在 allowed-once 后派发。

安装

在 git 检出的父目录执行（pnpm file: 安装：复制包并安装其声明的依赖）
dsh plugin --profile web add ./dsh-full-with-approval

或按绝对路径指向本地目录（link: 形式不会管理插件自身的依赖，检出目录里需先 npm install）
dsh plugin --profile web add /path/to/dsh-full-with-approval

发布为 npm 包后
dsh plugin --profile web add dsh-full-with-approval

dsh plugin add 会执行 pnpm 并协调 profile 的 bundle 列表：声明了 dsh.bundle 的包自动进入叠加层。下次启动 profile 时生效（重启应用 / HMR 后刷新）。

若 pnpm 报 ERR_PNPM_MINIMUM_RELEASE_AGE_VIOLATION（profile 锁文件的供应链策略，与本插件无关），安装时可放宽：
dsh plugin --profile web add ./dsh-full-with-approval --config.minimum-release-age=0

使用

- 在 Web UI 权限选择器里选 Full With Approval（第 4 项），或：
/permission full-with-approval

- 激活期间，受保护写入会弹审批；批准则该次写入放行。
- 随时可切回 workspace-write / danger-full-access / read-only；闸门跟随预设。

配置

插件条目配置（写在 profile 的 cordis.patch.yml 里覆盖）：

- id: full-with-approval
config:
glob，匹配相对会话工作区的 POSIX 路径；绝对 pattern 匹配绝对目标路径
protectedPaths:
- ".git/"
- ".env"
- ".env/**"
绝不弹窗的绝对 scratch 根目录（平台临时目录之外）
extraWritableRoots: []
shell 守卫层（默认 true）：bash/pwsh 命令带工作区外修改迹象即弹审批
bashGuard: true
追加"命令中出现即弹审批"的子串
extraBashTokens: []

修改 protectedPaths 在重载/重启后生效。

刻意不拦的部分

- 读取永远放行（所有模式都允许读）。
- 临时区（/tmp、os.tmpdir()）与 extraWritableRoots 从不弹窗。
- shell 写由启发式而非内核把关 —— 命令仍可绕过静态检查（运行时拼路径、cd 后相对写、解释器隐藏文件操作）。启发式倾向多问；请把它当作"疑似即提醒"层，而非安全边界。内核级边界仍是 workspace-write 模式（代价是 GPU 不可用）。

已知边界

- 选择器图标：核心 Web UI 的权限图标来自 @deepseek-ai/dsh-client-ui-conversation 客户端包内按值硬编码的表；插件新增的预设没有图标（客户端模块图是扁平的，插件包无法覆盖该表）。在上游支持之前，用一条命令补上第 4 档的「盾牌+对勾」图标（幂等、会备份包文件、web 应用实时提供该文件——刷新页面即可看到；每次升级 dsh 后重跑）：
node tools/patch-ui-glyph.mjs

- 第 4 项预设不显示核心 UI 中 danger-full-access 那一档的额外风险确认门（该确认按预设值硬编码在核心客户端）；不过每一笔受保护写入仍会逐次审批。
- run_code/代码模式执行不做文件效果检查；原生 write/edit 调用与 bash/pwsh 命令被闸门覆盖。
- 路径分类是"规范化后与工作区比较"；在符号链接别名怪异（Windows 8.3、大小写不敏感）的文件系统上，工作区边界请视为建议性——在受限模式下，内核级围栏才是权威。

发布

npm pack   # 打包

开发

npm ci                          # picomatch + harness 依赖
node --test                     # 分类器单元测试
DSH_AI_NODE_MODULES=/path/to/node_modules/@deepseek-ai \
node test/pre-execute.harness.mjs   # 真实注册表 ask→审批→派发全链路

另可参考 examples/cordis.patch.yml（显式旋钮值）与 SECURITY.md / CONTRIBUTING.md（信任模型与改动规则）。

License

MIT