前言¶
在 DeepSeek Harness（DSH）里，bash、write 等 escalating 工具会暴露 sandbox_permissions 与 justification 参数。Core 只接受「与当前模式相同或更宽」的权限声明；若模型填了一个比当前会话更窄的值，调用会在命令真正执行前就失败，并出现类似下面的错误：
Error: sandbox escalation to "workspace-write" is not strictly wider than this call's current "danger-full-access" mode
这类问题在接入 GPT 系模型时较常见：它们常在 Codex shell 工具上训练，习惯把可选字段都填上，而 DSH 的枚举里没有「使用默认」项，模型往往会选 workspace-write。当会话已是 danger-full-access 时，这相当于请求一次无效的「收窄」，Core 会直接拒绝。
下面介绍社区插件 dsh-sandbox-noop-escalation（维护者 zzstar101，分类 admin-security）。它在工具执行前改写参数，去掉那些本来就不会改变沙箱宽度的冗余字段，让只读或已在最高权限下的调用照常执行，而不放宽任何权限。
这是什么¶
dsh-sandbox-noop-escalation 是一个 DSH 插件：在 tools/pre-execute 钩子里，对比本次调用请求的 sandbox 模式与会话当前解析出的模式；若请求无法放宽当前模式，则移除 sandbox_permissions 和 justification，避免触发 not strictly wider 类错误。
插件不会扩大权限，只删除「即使保留也不会改变模式」的请求。源码与说明见 GitHub 仓库，社区目录页为 SkillHub 条目。许可证为 MIT，当前 package 版本为 0.2.0。
为什么会出现 not strictly wider¶
DSH 的 escalating 工具（bash、pwsh、write、edit、run_code）在 schema 里固定枚举 ["workspace-write", "danger-full-access"]。Core 的规则是：字段值必须是当前模式，或严格更宽的模式。
GPT 模型容易在每次调用里都带上 sandbox_permissions（例如 plain 只读命令也填 workspace-write）。在已是 danger-full-access 的会话里，workspace-write 比当前模式窄，于是整次调用被拒，且错误发生在 pre-execute 阶段，与命令本身是否安全无关。
Codex shell 工具还使用 use_default、require_escalated、with_additional_permissions 等同名字段值；模型有时会把这些值原样带进 DSH。插件对空值与 use_default 一律视为「未请求」并清理；对后两者仅在会话已 unrestricted 时清理，在更窄会话中保留交给 DSH 处理，避免擅自映射成更宽权限。
核心功能¶
插件在每次被监听工具执行前，按请求模式与当前模式的关系处理参数，行为如下（与 README 一致）：
| 调用参数情况 | 处理 |
|---|---|
| 请求模式等于或窄于当前模式 | 移除 sandbox_permissions 与 justification |
sandbox_permissions 为 null、空或 Codex 的 use_default |
任意模式下移除上述两字段 |
会话已在 danger-full-access |
移除两字段（不存在更宽模式） |
仅有 justification、无 sandbox_permissions |
移除 justification |
| 请求模式严格宽于当前模式 | 不改动，由 DSH 按惯例走审批 |
| 未知请求模式或当前模式无法解析 | 不改动，由 DSH 决定 |
实现上只处理注册 schema 里带有 DSH 自有 escalation 字段的工具，避免误改第三方复用同名字段的工具。改写发生在执行前，不依赖匹配错误文案，也不消耗一次失败的重试。
安装与启用¶
可从 DSH 插件市场安装，或用 CLI 指定 profile：
dsh plugin --profile <name> add dsh-sandbox-noop-escalation
包内带有 dsh.bundle.patch，安装后会自行挂载，一般无需手改 profile 结构。
插件以当前 DSH 进程权限运行；安装前建议自行查看仓库源码与 MIT 许可证，确认符合你的安全策略。
配置¶
默认监听工具：bash、pwsh、write、edit、run_code。可在 profile 的 cordis.patch.yml 中覆盖：
- id: sandbox-noop-escalation
config:
tools: [bash, pwsh]
| 配置项 | 类型 | 默认值 | 含义 |
|---|---|---|---|
tools |
string[] |
["bash", "pwsh", "write", "edit", "run_code"] |
要监听的工具名；空数组则禁用插件 |
兼容性与依赖¶
README 记载在 DSH 0.2.0-rc.2（cordis 4.0.4）上测试。插件依赖 tools/pre-execute 钩子以及 tools、sandboxPolicy 服务；缺任一则不加载。若策略无法解析，仅会清理空值与 use_default，其余参数原样透传。
运行环境要求 Node.js >= 20；peer 依赖 @deepseek-ai/cordis ^4.0.1。
适用场景与注意¶
适合： 使用 GPT 或其它习惯填满工具 optional 字段的模型跑 DSH；会话经常处于 danger-full-access 或较宽沙箱，却反复因冗余 workspace-write 被拒；希望减少无意义的 escalation 失败，同时仍保留「真正需要加宽」时的 DSH 审批流程。
注意：
- 插件从不主动加宽权限；真正更宽的请求仍会走 DSH 原有流程。
- 第三方工具若只是复用了相同字段名但语义不同，不会被插件改写。
- SkillHub 等社区目录为独立站点，与 DeepSeek / 幻方无官方从属关系；插件市场条目与 GitHub 为同一项目的不同入口。
结尾¶
若你在 DSH 里用 GPT 类模型时频繁看到 sandbox escalation「not strictly wider」错误，可以先安装 dsh-sandbox-noop-escalation，让无效的 sandbox_permissions / justification 在 pre-execute 阶段被去掉，再观察 escalating 工具是否恢复正常。
- 目录页：https://www.skillhub.cn/plugins/zzstar101/dsh-sandbox-noop-escalation
- GitHub：https://github.com/zzstar101/dsh-sandbox-noop-escalation
