沙箱权限升级拦截 sailoflight/dsh-bash-escalation

dsh-bash-escalation

本地 DSH 插件，用来阻止模型在 bash 工具上发送冗余 / 非扩大范围的 sandbox_permissions。此前这类请求会直接硬失败，报错如下：

Error: sandbox escalation to "<mode>" is not strictly wider than this call's current "<mode>" mode

两个插件，都按 DSH 配置档（web、dsh-tui、headless）安装：

| 插件 | 引用方式（相对路径） | 类型 | 作用 |
| bash-escalation | ./plugins/bash-escalation/index.js | 提示词 | 增加一段系统提示词：只有当请求的模式严格宽于会话当前模式时，才设置 sandbox_permissions；相等或更窄 → 省略。 |
| bash-redundant-escalation-noop | ./plugins/bash-redundant-escalation-noop/index.js | 机制 | 在解析时就地包装每个支持提权的工具的 execute（bash、文件系统的 write/edit 工具、pwsh —— 凡是参数 schema 里声明了 sandbox_permissions 的工具），因此无论全局定义还是按智能体定义（由预设挂载）都能覆盖，不管它们何时出现 —— 并且只在请求 ≤ 当前模式时剥掉 sandbox_permissions/justification（这从来不是真正的提权）。真正的提权原样放行。不支持提权的 bash 变体（来自自定义智能体预设、由 PTY 支撑的持久/终端 bash）会按原样报错，而不是悄悄忽略真正的提权。 |

机制插件为什么在解析时包装

插件给工具注册表上的 ctx.tools.get 打补丁，并就地覆盖解析出的 bash 定义的 execute 方法。在访问时包装，而不是在发现时包装，这正是关键所在：

- 会话看到的 bash 并不是一个稳定对象。 在 web 配置档里，全局的 tool-bash 行是禁用的；每个会话挂载一个智能体预设，往该智能体的作用域层注册一份全新的 bash 定义。TUI/headless 则保留进程级全局的一份。对象在运行时出现又消失 —— 会话创建、预设（重新）挂载、HMR 重新注册。
- 只包装 apply / agent/created / tools/change 时刻可见的对象，偶尔会漏掉一个（agent/created 触发时预设的 bash 还没挂载；某次 tools/change 扫描时某个智能体还不在 agents.list() 里），于是该会话实际生效的 bash 随后退化到那个未包装的对象，再次硬失败，报 sandbox escalation ... is not strictly wider ...。
- 每次派发都会在调用时通过 ctx.tools.get(name, scope) 重新解析工具，所以给 get 本身打补丁，就能覆盖任何可能执行的 bash —— 全局的或按智能体的，无论何时出现，包括 HMR 之后的替换对象 —— 在它第一次被解析的那一刻。apply 时的主动扫描和 agent/created / tools/change 监听器保留下来，作为双保险。
- 不复制任何东西：schema、描述、参数、展示和超时都保持原对象自己的实时属性。包装器委托给 捕获的是真实 execute，所以不会递归，正常调用、真正的提权，行为都与真实工具逐字节一致。
- HMR / 重复应用安全：包装标记记录 { real, wrapped }，模块重新加载时会还原原始 execute，再用全新的闭包重新包装（不会留下指向已释放 ctx 的过期包装器）；get() 补丁在 dispose 时还原，重新应用时重新安装。
- 故障安全：任何问题都只记一条警告，原版 bash 保持不动。解析不出会话当前生效的沙箱模式时，我们直接放行，不去猜——错误地剥离会绕过真实的用户审批。

Bash 变体（自定义智能体预设）

会话里的 bash 不总是原版 @deepseek-ai/dsh-tool-bash。自定义智能体预设可以禁用那一行，在同一个工具名 bash 下挂载别的实现：

- @deepseek-ai/dsh-terminal-bash + @deepseek-ai/dsh-tool-bash-persistent（PTY 支撑的持久 shell），例如用户安装的 liangshen 预设（~/.dsh/.agent-presets/liangshen/agent.cordis.yml）：它的 - id: tool-bash ... disabled: true 行，加上一个 persistent-shell 组，挂载 persistent-bash / terminal-bash。

这些变体的参数 schema 只声明 command——工具根本没有提权机制。机制插件从定义自己的参数 schema 推断是否支持提权（有没有声明 sandbox_permissions），所以行为跟着组合实际挂载的 bash 走。

插件不只管 bash：同样的冗余提权失败也出现在文件系统工具上（dsh-tool-fs 的 write/edit——观察到的「not strictly wider」和「invalid justification」错误来自 edit/write，不是 bash），以及 dsh-tool-pwsh 上。get() 补丁会包装任何参数 schema 声明了 sandbox_permissions 的工具（外加始终包装 bash，这样无 schema 的 PTY 变体仍会明确报错），所以 write/edit/pwsh 得到同样的剥离/放行处理，无需逐工具配置。

各工具的行为：

| 情况 | 原版 bash | 持久 / terminal bash 变体 |
| 参数里没有 sandbox_permissions | 放行 | 放行 |
| 冗余（请求 ≤ 会话模式） | 剥离，运行 | 剥离，运行 |
| 真正提权（请求 > 会话模式） | 放行 → 审批流程 + 严格放宽检查 | 明确报错：sandbox_permissions is not available in this composition (no sandboxing executor to escalate) |

明确报错（而不是让变体悄悄忽略请求）很重要：真正的提权交给 PTY 支撑的 bash，命令会在当前更窄的模式下运行，沙箱会再次拒绝，模型却看不到任何原因。这个错误就是原版工具在无法提权的组合下给出的那条消息。

目录结构

dsh-bash-escalation/
├── install.sh # clean installer (no pnpm, no network, no absolute paths)
├── uninstall.sh # 干净卸载脚本 ├── README.md ├── test/ │ └── mechanism.test.mjs # 回归测试（node test/mechanism.test.mjs） └── plugins/ ├── bash-escalation/ → 复制到每个配置档的 plugins/ └── bash-redundant-escalation-noop/

安装

bash <path-to>/dsh-bash-escalation/install.sh

然后重启每个 DSH 终端（web / tui / headless）。

安装器对每个配置档做的事：
1. 把两个插件复制到 ~/.dsh/profiles//plugins/（DSH 本地插件的标准目录）。只动我们自己命名的目录。
2. 写入 cordis.patch.yml 条目，用相对路径 ./plugins/... 引用。
3. 清理旧的 node_modules/@dsh-local 符号链接。

不写 node_modules，不用 pnpm，不联网，任何地方都不写绝对路径。 源位置在运行时从脚本自身路径推导，所以项目克隆到哪里都能用，也绝不会干扰别人的插件或他们的 pnpm install。

测试

机制插件自带一套零依赖回归测试：

node test/mechanism.test.mjs

覆盖了「访问时包装」设计要修的那个故障——在 apply 之后才挂载的新 per-agent bash，对 agent/created / tools/change 不可见，必须在它第一次 get() 解析时包装——另外还覆盖：冗余升级与真实升级、策略解析失败（直接放行，绝不错误剥离）、HMR 重新 apply（新包装器，不链式打补丁）、dispose（get() 恢复）、不支持升级的 bash 变体（冗余剥离，真实升级按原生消息大声失败，普通调用放行），以及非 bash 的升级工具（fs 风格的 write 按 schema 包装，冗余升级剥离，真实升级放行；没有升级字段的工具保持不动）。

说明

- 能扛住 npm update --global @deepseek-ai/dsh（配置档在 ~/.dsh 下，不在全局 CLI 的 node_modules 里）。
- 配置档重建后，重跑 install.sh 重新安装。

GitHub

托管在 github.com/sailoflight/dsh-bash-escalation（SSH 远程 git@github.com:sailoflight/dsh-bash-escalation.git）。改动在你自己的真实终端里用普通 git 命令提交并推送（使用 GitHub SSH 密钥 ~/.ssh/id_ed25519_github）。