dsh-sandbox-noop-escalation
DeepSeek Harness 插件：删除无法扩大当前沙箱模式的 sandbox_permissions/justification 字段，避免冗余的权限提升请求（GPT models 中很常见）因“not strictly wider”而失败。
插件会安装到这里；不确定时保持 web。
npx -y @deepseek-ai/dsh plugin --profile web add dsh-sandbox-noop-escalation@0.2.0Sandbox Noop Escalation 以 dsh-sandbox-noop-escalation 发布，当前版本为 0.2.0。Plugin Hub 会校验它的 manifest，并保存精确安装来源，便于复现安装结果。
A DeepSeek Harness plugin that removes sandbox_permissions / justification arguments when they cannot widen the call's current sandbox mode. Without it, a call like this fails before the command runs:
Error: sandbox escalation to "workspace-write" is not strictly wider than this call's current "danger-full-access" mode
DSH's escalating tools (bash, pwsh, write, edit, run_code) advertise a fixed enum ["workspace-write", "danger-full-access"] for sandbox_permissions. Core accepts the field only when it names the current mode or a strictly wider one.
GPT models, trained on Codex's shell tool (which has fields with the same names), tend to fill every optional field on every call, including plain read-only commands. Because the enum has no "use the default" value, they usually pick workspace-write. In a danger-full-access session that is narrower than the current mode, so the call is rejected.
Before each call to a watched tool runs (on the tools/pre-execute hook), the plugin compares the requested mode with the mode the session's sandbox policy resolves for that call:
| Call arguments | Action |
|---|---|
| requested mode equal to or narrower than the current mode | remove sandbox_permissions and justification |
sandbox_permissions is null, empty, or Codex's use_default | remove both fields, in any mode |
session already at danger-full-access (e.g. Codex's require_escalated) | remove both fields: nothing is wider |
justification without sandbox_permissions | remove justification |
| requested mode wider than the current mode | leave unchanged; DSH asks for approval as usual |
unknown requested mode below danger-full-access, or current mode cannot be resolved | leave unchanged; DSH decides |
Codex's own shell tool uses use_default / require_escalated / with_additional_permissions for the same field, and GPT models sometimes carry those values over. use_default and empty values are treated as "no request". The other two are only removed when the session is already unrestricted; in a narrower session they are left for DSH to reject, because guessing how wide they should map would be granting permissions.
It only touches tools whose registered schema advertises DSH's own escalation fields, so third-party tools that reuse the names are ignored. The call is rewritten before it runs, so no failed attempt is spent, and the plugin does not match on error text.
It never widens permissions. It only removes a request that would not have changed the mode anyway.
From the DSH plugin market, or with the CLI:
dsh plugin --profile <name> add dsh-sandbox-noop-escalation
The package ships a dsh.bundle.patch, so it mounts itself; no profile edits are needed.
| Key | Type | Default | Meaning |
|---|---|---|---|
tools | string[] | ["bash", "pwsh", "write", "edit", "run_code"] | Tool names to watch. An empty list disables the plugin. |
Override it from your profile's cordis.patch.yml:
- id: sandbox-noop-escalation
config:
tools: [bash, pwsh]
Tested with DSH 0.2.0-rc.2 (cordis 4.0.4). It relies on the tools/pre-execute hook and the tools and sandboxPolicy services. If any of them is missing, the plugin does not load; if the policy cannot be resolved, only empty / use_default values are removed and everything else passes through unchanged.
npm test
MIT