dsh-approve-for-me:DeepSeek Harness 自动沙箱审批
English | 中文
 
规则限定范围,可选大模型复核;拿不准时交回 Harness 原生人工审批。
dsh-approve-for-me 是 DeepSeek Harness 的自动沙箱审批(automatic sandbox approval)插件,用于 Shell 和 PowerShell 的沙箱扩权(sandbox escalation)。它依次执行固定高风险检查、字面命令前缀规则和可选的无工具大模型复核器(LLM reviewer)。成功时只授予当前请求一次 allowed-once,不会永久授权。
0.2.2 已适配 DeepSeek Harness 0.1.1-rc.1,包括 rc1 的第三方插件 keyed 设置卡片机制和共享客户端 settings schema service。
> [!WARNING] > 本项目不是 DeepSeek 官方插件,未经独立安全审计且不提供担保。内置检查无法覆盖所有命令、参数、wrapper 和环境差异。请使用尽可能窄的正向允许列表(allowlist),并为重要操作保留 Harness 原生人工审批。
快速使用
npm install -g @deepseek-ai/dsh
dsh plugin --profile web add dsh-approve-for-me@latest
dsh web --host 127.0.0.1 --port 3080然后:
1. 打开 Settings -> Plugins -> Plugin configuration -> Approve for me。 2. 只添加你愿意自动复核的命令前缀。 3. 为目标 agent 或 session 选择 Approve for me Access preset。
> [!IMPORTANT] > commandPrefixes 默认为空。只安装插件不会自动批准任何命令。
@latest 是 npm dist-tag,不是固定版本号。只有明确测试 beta 通道时才使用 @beta;需要可复现安装或回滚时使用 @<version>。不建议把无后缀包名作为升级命令:Profile 可能已经锁定具体版本,此时 pnpm 会显示 Already up to date,但不会改写版本。
为什么使用它
| Access 方式 | 沙箱扩权行为 |
|---|---|
| Harness 原生审批 | 每次扩权都询问用户 |
Approve for me | 执行固定检查和用户规则,可选调用模型,不确定时询问用户 |
Full access | 关闭沙箱审批边界 |
规则决定自动审批的最大候选范围。reviewer 只能收紧范围,不能绕过规则或固定高风险检查。
Web 配置
添加范围明确的字面前缀,例如:
<img width="560" alt="Approve for me Web settings" src="https://github.com/user-attachments/assets/ba3df97b-3d35-47b7-a8a4-cd7772c48eb6" />
Shell: git status
Shell: git diff
PowerShell: Get-Location
PowerShell: Get-Content -LiteralPath README.md规则匹配经过解析的 token 前缀,不是整条命令完全相等。后面仍可追加参数,因此应尽量写明子命令和路径。复合命令中的每个分段都必须分别匹配。
即使前缀看似匹配,已知的包管理器生命周期动作、带路径的可执行文件、直接脚本、wrapper、会写入的 PowerShell alias、解析歧义和固定高风险形态仍会转人工审批。
Web 卡片是可选配置入口。rc1 客户端以 key approve-for-me 注册 keyed settings.plugin.item slot,并使用 Harness 共享的 settings schema service。卡片只在 loopback 连接中显示,通过插件自己的 loopback-only RPC 读写配置。持久化、schema 校验、revision conflict、脱敏和热加载由 Harness Settings service 负责。卡片不做审批决策,也不依赖 llm-pi-ai。
检查 Profile 实际安装的版本:
dsh plugin --profile web list dsh-approve-for-me --depth 0测试时应确认:匹配的只读扩权可以获得一次性批准;未匹配或高风险请求仍显示原生人工审批;切换到其他 Access preset 后插件不再参与当前 session 的审批。
安装与升级
插件和设置按 Profile 隔离。web、headless、tui 和自定义 Profile 需要分别安装。
# Web 设置卡片 + Host 审批核心
dsh plugin --profile web add dsh-approve-for-me@latest
# 不使用 Web 设置卡片的 Host 审批核心
dsh plugin --profile headless add dsh-approve-for-me@latest
# 检查有效接线
dsh --profile web --dump-config
dsh --profile headless --dump-config
# 从一个 Profile 卸载
dsh plugin --profile web remove dsh-approve-for-me配置转储应包含 approve-for-me permission preset 和 Host 插件条目。
升级正在运行的 Web Profile
1. 在运行 dsh web 的终端按 Ctrl+C 停止 Host。 2. 请求 npm 当前的 latest dist-tag。 3. 检查实际安装版本。 4. 重启 Host。 5. Host 启动后再刷新浏览器。
dsh plugin --profile web add dsh-approve-for-me@latest
dsh plugin --profile web list dsh-approve-for-me --depth 0
dsh web --host 127.0.0.1 --port 3080单独刷新浏览器不会重载 Host 进程,也不会更新 Profile lockfile。
如果 @latest 没有更新,先指定具体已发布版本:
$version = '<published-version>'
dsh plugin --profile web add "dsh-approve-for-me@$version"
dsh plugin --profile web list dsh-approve-for-me --depth 0如果仍锁定旧版本,保持 Host 停止,先 remove 再重新 add:
dsh plugin --profile web remove dsh-approve-for-me
dsh plugin --profile web add dsh-approve-for-me@latest
dsh plugin --profile web list dsh-approve-for-me --depth 0测试 beta 时使用 dsh plugin --profile web add dsh-approve-for-me@beta。其他 Profile 需要单独升级。
YAML 配置
Web 页面和 $DSH_HOME\settings.yaml 修改同一份 approve-for-me 设置。Web 只是可选写入方式。
推荐:规则 + 当前会话模型
省略 reviewer.provider 和 reviewer.model,每次复核继承发起审批请求的 session provider/model:
approve-for-me:
version: 1
mode: rules-and-llm
rules:
commandPrefixes:
- tool: shell
prefix: git status
- tool: shell
prefix: git diff
- tool: pwsh
prefix: Get-Content -LiteralPath README.md
reviewerInstructions: >-
Only allow read-only repository inspection.
reviewer:
timeoutMs: 30000
limits:
trustedTranscriptChars: 12000
untrustedToolDataChars: 8000
reviewerOutputChars: 2000如果请求 session 没有完整的 provider/model 路由,reviewer 不会自动允许,请求转人工审批。
需要固定路由时,同时填写两个标识:
reviewer:
provider: your-provider-id
model: your-model-id
timeoutMs: 30000模型凭据仍由 Harness 管理,插件只保存 provider/model 标识。
不需要模型复核时设置 mode: rules-only。关联检查、命令解析、固定高风险检查和规则匹配仍会执行。
字段限制
| 字段 | 默认值 | 限制 |
|---|---|---|
mode | rules-and-llm | rules-only 或 rules-and-llm |
rules.commandPrefixes | [] | 最多 200 条;tool 为 shell 或 pwsh |
单条 prefix | 无 | 一个非空字面命令分段,最多 1000 字符 |
rules.reviewerInstructions | '' | 最多 8000 字符 |
reviewer.timeoutMs | 30000 | 1000 到 120000 毫秒 |
| reviewer 内容边界 | 12000 / 8000 / 2000 | 每项 256 到 100000 字符 |
reviewer.provider/model | 当前 session | 同时填写或同时省略 |
已开始的复核使用启动时取得的配置快照;热加载只影响之后的请求。
安全模型
默认行为:
- 模式为
rules-and-llm。 - reviewer provider/model 继承发起请求的 session。
- 正向命令规则为空。
- 固定高风险检查先于用户规则和 reviewer。
- 每次复核使用全新的无工具 agent。
- 失败、超时、无效输出、歧义或不匹配都会转人工审批。
决策顺序:
1. 当前 Access preset 必须是 approve-for-me。 2. 请求必须是受支持的 Shell 或 PowerShell 扩权,并能严格关联到当前工具调用。 3. 命令必须通过固定高风险检查。 4. 每个命令分段都必须匹配对应工具的字面前缀。 5. rules-only 返回一次 allowed-once;rules-and-llm 还要求 reviewer 返回结构正确的明确 allow。
内置检查覆盖一组有限的常见风险,包括解析失败、文件或权限修改、系统和包管理变更、Git/GitHub 写操作、包管理器生命周期脚本、带路径的可执行文件、动态命令执行、凭据访问和外部写入。它们是保守分类器,不能证明未命中的命令一定安全。
高风险结果会停止自动审批并把请求交回 Harness,不会直接拒绝命令。
权限与数据
| 项目 | 行为 |
|---|---|
| 审批上下文 | 读取当前 escalation、关联工具调用和有长度上限的 transcript |
| reviewer 输入 | 区分可信说明与不可信工具数据,限制长度并清理常见凭据格式 |
| reviewer 权限 | 使用全新 agent,不提供工具 |
| 网络 | 使用 Harness 已配置的 provider 路由 |
| Web 写入 | loopback-only RPC 委托 Settings service 持久化 |
| 批准范围 | 只为当前请求返回一次 allowed-once |
故障排查
| 现象 | 检查 |
|---|---|
Access 中没有 Approve for me | 安装到当前 Profile,重启,并检查 --dump-config |
| Web 设置卡片不显示 | 使用 web Profile,并通过 127.0.0.1 或其他 loopback 地址访问 |
| 命令匹配但仍询问 | 检查复合命令各分段、高风险信号、工具类型和 reviewer 结果 |
| reviewer 没有运行 | 确认使用 rules-and-llm、规则完整匹配且 session 模型路由有效 |
| provider/model 校验失败 | 同时填写两项,或同时清空 |
| 保存提示 revision conflict | 重新加载卡片,基于最新值编辑并保存 |
| 安装出现 peer warning | 确认 Harness 0.1.1-rc.1 兼容性,并运行 pnpm check |
| 另一个 Profile 不生效 | 在该 Profile 中单独安装和配置 |
常见问题
如何自动审批 DeepSeek Harness sandbox escalation?
安装插件、添加范围明确的命令前缀,然后选择 Approve for me Access preset。只有严格关联、通过固定检查并满足当前复核模式的请求才会获得一次性批准。
它会替代 Full access 吗?
不会。插件保留沙箱边界,并把不确定请求交回 Harness 原生审批。
是否有内置规则?
有固定高风险检查,但没有内置正向 allowlist。正向规则必须符合当前项目和威胁模型。
高风险命令会被直接拒绝吗?
不会。0.2.2 会停止自动审批,把决定交回用户。
reviewer 能扩大 allowlist 吗?
不能。规则先确定最大候选范围,reviewer 只能允许匹配请求或交回人工。
headless 能使用吗?
能。在 headless Profile 中单独安装并配置 YAML。Host 审批核心不依赖 Web 卡片。
兼容性
| 项目 | 基线 | | --- | --- | | DeepSeek Harness | 0.1.1-rc.1 | | Node.js | ^22.19.0 || >=24.0.0 | | Cordis | ^4.0.1 | | npm 通道 | 稳定版使用 @latest;beta 测试使用 @beta |
rc1 适配使用 Harness 要求的 keyed 第三方设置卡片注册方式和 settingsSchema service;已移除 rc7 的 schema-form 依赖。权限 patch 保留 Read Only、Workspace Write 和 Full access,再添加 Approve for me。permission preset 图标仍由 Harness UI 控制。
2026 年 8 月 21 日,0.2.2 源码已针对官方 dsh-v0.1.1-rc.1 tag 的提交 528c682e 完成验证:
- typecheck、完整回归测试、coverage 和生产构建通过。
- npm pack 生成 26 个文件,包含两份 README。
- 兼容性 workflow 覆盖 Ubuntu、Windows,以及 Node 22.19 和 24,并包含 Windows PowerShell 路径。
- 回归测试覆盖 rc1
permission/preset.origin、共享settingsSchema注入、一次性 PowerShell 关联、持久 PowerShell 回退、设置冲突、重连和非 loopback 行为。 - 在隔离的 DSH home 中,rc1 Web Profile 已加载插件,并成功返回 Web 页面和插件 client bundle;rc1 headless Profile 读取 YAML 的
permission.defaultPreset: approve-for-me,通过本地 mock LLM 完成一次受控 Bash 提权。会话日志记录了 origin 为default的permission/preset、approval/decided: allowed-once和成功的工具结果。
2026 年 8 月 15 日曾使用 rc.6 完成 headless 单次批准和 Web bundle 加载 smoke test。这是历史记录,不是当前兼容性基线。
开发与验证
pnpm install --frozen-lockfile
pnpm check
pnpm test:coverage
npm pack --dry-run --json --ignore-scripts需要对指定 Harness 源码 checkout 运行客户端测试时:
$env:DSH_HARNESS_ROOT = 'H:\path\to\deepseek-harness'
$env:DSH_HARNESS_TSCONFIG = 'H:\path\to\deepseek-harness\tsconfig.base.json'
pnpm test测试 adapter 是临时文件,Git 会忽略它。运行时验证应使用新的隔离 DSH_HOME。
本地 tarball
npm pack --json
$package = Get-ChildItem '.\dsh-approve-for-me-*.tgz' |
Sort-Object LastWriteTime -Descending |
Select-Object -First 1
dsh plugin --profile web add $package.FullName发布标签
稳定版使用 publishConfig.tag: latest,因此 npm publish 会更新 latest。预发布版本应使用 npm publish --tag beta,只更新 beta,不移动 latest。
安全与许可证
请通过 GitHub Security Advisories 私下报告漏洞。不要提交 API key、凭据、完整 prompt、私有路径或未脱敏的工具参数。详见 [SECURITY.md](SECURITY.md)。
感谢 LINUX DO 社区提供帮助和反馈。
本项目使用 [MIT License](LICENSE)。