fix proposal: non-widening sandbox_permissions should be a no-op, not an error (GPT-family models loop on it)

[Rogers-F]

Problem

GPT-family models are heavily trained on shell-tool conventions where escalation fields (with_escalated_permissions + justification) may ride any call speculatively. Under DSH they habitually attach sandbox_permissions to bash calls whose effective mode already suffices, and the verbatim error

Error: sandbox escalation to "danger-full-access" is not strictly wider than this call's current "danger-full-access" mode

turns that trained habit into a hard failure loop: the model reads the error as a denial, escalates again (sometimes inventing a justification such as "none" to satisfy the non-empty check), and burns turn after turn without ever running the command.

Observed live on dsh web (0.1.0-rc.7, reproduced on 0.1.1-rc.1 sources) with GPT-series models in the executor role: every single bash call failed this way, across fresh sessions, and the model eventually routed around its own shell by delegating to subagents — which inherit the same habit.

Prompt-level mitigation does not stick. We tried twice with increasingly explicit persona rules (down to "when you see not strictly wider, drop both fields and resend"); the habit is trained in, and the tool description's own escalation clause ("escalating up front is fine only when this session already denied the same access") reinforces the loop after the first error, because the model misreads the argument error as a denial.

Why a no-op is safe

A non-widening request is behaviorally identical to the call the model should have made:

• nothing widens — the call runs under the confinement it already had;
• nobody is prompted — same as today (A non-widening request never prompts a human);
• the fail-closed sequence for widening asks is untouched: strict widening + non-empty justification + user approval through ctx.approval are all still required before anything runs wider.

The only thing that changes is that a semantically meaningless argument stops being a hard error that burns the call.

call	today	proposed
non-widening sandbox_permissions (any justification state)	not strictly wider error, command never runs	runs at current mode, no prompt
lone justification	only valid together with sandbox_permissions error	ignored, command runs
widening, missing/blank justification	pairing error	same errors, kept
widening, justified	approval prompt → grant/reject	unchanged

Complete implementation, ready to take

Since external PRs are not accepted at this stage, we put the full change on a public branch — feel free to cherry-pick or reimplement:

https://github.com/Rogers-F/deepseek-harness/tree/fix/tolerate-non-widening-sandbox-escalation

Scope (15 files, +104/−98):

• packages/sandbox/sandbox/src/escalation.ts — approveEscalation resolves a non-widening request as a no-op grant of the call's effective mode; the justification checks move into the widening path (an approval prompt still never fires without a reason); validateEscalationArgs is removed since the widening path now owns its guards and a lone justification drives nothing.
• tool-bash / tool-pwsh / tool-fs — enter escalation on sandbox_permissions alone and delegate the judgment to approveEscalation.
• Tests updated across the four packages (230 tests in the touched files pass; pnpm typecheck clean; lefthook staged gates pass).
• Both shell tool READMEs (en/zh) and their translation-pairing records updated.

Happy to rework it behind a config switch instead of the new default if you'd prefer, or adjust in any other direction — the branch is there to be taken, not to be merged as-is.

---

中文摘要

问题：GPT 系模型被 Codex 风格的 shell 工具约定（with_escalated_permissions + justification 可随时预防性携带）深度训练过，在 DSH 里会习惯性地给 bash 调用带上 sandbox_permissions。当会话已是最宽模式时，not strictly wider 硬报错会让模型把"参数错误"误读成"沙箱拒绝"，于是反复升权、连环失败，一条命令都跑不成，最终绕道子代理（子代理同样带这个习惯）。提示词层面压制两轮均告失败——这是训练进权重里的惯性。

方案：未拓宽的升权请求改为无操作放行（按当前模式照常执行，不弹任何审批）——它与"模型本该发出的那次调用"行为完全等价，安全面零变化；真正要求拓宽的请求完整保留 fail-closed 链路：严格更宽 + 非空理由 + 用户审批，缺一不可。

完整实现已放在上面的公开分支（含 4 个包的源码、测试、中英文档同步，相关 230 个测试全绿），欢迎直接 cherry-pick；如果团队倾向做成配置开关而非默认行为，我们也乐意配合调整。

[istarwyh]

Independent confirmation on 0.1.1-rc.2 (Codex provider)

I independently reproduced this on the newest published release available to me, including both shell and filesystem tool paths. The bug is still present in 0.1.1-rc.2 and in current master at b150a551b8d465e31e418e1b2eaf5e79bbb7d28e.

Environment

• @deepseek-ai/dsh: 0.1.1-rc.2
• @deepseek-ai/dsh-sandbox: 0.1.1-rc.2
• @deepseek-ai/dsh-tool-bash: 0.1.1-rc.2
• @deepseek-ai/dsh-tool-fs: 0.1.1-rc.2
• Provider/model: codex / gpt-5.6-sol
• Session sandbox mode: danger-full-access
• macOS 26.3 (25D125), Node.js 24.14.0, npm 11.9.0

Live behavior

The Codex provider systematically materializes optional tool fields. A first-attempt Bash smoke call contained:

{
  "command": "echo RC2_SMOKE",
  "timeoutMs": 120000,
  "workdir": "/workspace",
  "run_in_background": false,
  "sandbox_permissions": "danger-full-access",
  "justification": ""
}

An Edit call in the same full-access session likewise contained:

{
  "file_path": "/workspace/smoke.txt",
  "old_string": "before-rc2",
  "new_string": "after-rc2",
  "replace_all": false,
  "sandbox_permissions": "danger-full-access",
  "justification": ""
}

Before applying a local compatibility patch, a real filesystem mutation with a non-empty justification failed before touching the file:

Error: sandbox escalation to "danger-full-access" is not strictly wider than this call's current "danger-full-access" mode

When justification is materialized as an empty string, the current validation order can instead fail one step earlier with:

Error: invalid justification: expected a non-empty sentence

Both failures have the same underlying cause: fields that are semantically irrelevant because the standing policy already covers the request are validated as if they were a genuine escalation.

Deterministic helper-level reproduction

The failure does not require an LLM once the arguments exist:

await approveEscalation(
  {
    requestedMode: 'danger-full-access',
    effectiveMode: 'danger-full-access',
    justification: 'already allowed by the standing policy',
    subject: 'command',
  },
  {
    approver: undefined,
    agent: undefined,
    callId: 'repro',
    toolName: 'bash',
  },
)

Expected: resolve to danger-full-access without invoking an approver.
Actual: throws not strictly wider.

Current source path

• validateEscalationArgs rejects a blank reason before the effective mode is known.
• approveEscalation rejects equality and narrower requests before the approval path.
• tool-bash advertises the optional fields and resolves them before execution, then calls the shared helper at L330-L339.
• Filesystem mutations share the same behavior through FsSandboxController.resolvePolicy.

This is therefore a backend compatibility/robustness issue rather than a Web UI rendering issue or a Bash/Edit implementation issue.

Safety-preserving resolution semantics

The effective policy should be resolved in this order:

1. If the requested mode is equal to, or already covered by, the effective mode, return the effective mode immediately. Do not prompt and do not downgrade.
2. Only for a genuine widening request, require a non-empty justification.
3. Keep the existing strict-wider check, approval-channel checks, and outcome handling for that genuine widening request.

The important empty-string edge is that justification: "" must not reject an already-satisfied request; it must still reject a genuine widening request before any approval prompt.

Suggested regression matrix

Effective	Requested	Justification	Expected result	Approver calls
danger-full-access	danger-full-access	empty	keep danger-full-access	0
danger-full-access	workspace-write	empty	keep danger-full-access (no downgrade)	0
workspace-write	workspace-write	empty	keep workspace-write	0
workspace-write	danger-full-access	empty	invalid justification	0
workspace-write	danger-full-access	non-empty, allowed	return danger-full-access	1
workspace-write	danger-full-access	non-empty, no service	requires approval	0
workspace-write	danger-full-access	non-empty, rejected	user rejected	1
read-only	workspace-write	non-empty, allowed	return workspace-write	1

Tool-level coverage should include at least one Bash/Pwsh call and one Edit/Write call under an effective danger-full-access policy with all optional fields materialized.

Local verification of the proposed semantics

With the no-op check placed before reason validation, the exact first-attempt Bash and Edit calls shown above both completed with isError: false. A genuine workspace-write -> danger-full-access request still required a non-empty reason and invoked the approver exactly once.

This independently confirms the report and the safety argument in the original post on 0.1.1-rc.2.

[Rogers-F]

Thank you for the thorough independent confirmation — the deterministic helper-level repro and the regression matrix are exactly what this needed, and the Codex-provider observation (optional fields systematically materialized with justification: "") makes the case even stronger than the speculative-habit framing in the original post.

To confirm against your resolution semantics: the branch at Rogers-F/deepseek-harness:fix/tolerate-non-widening-sandbox-escalation implements precisely that ordering:

1. approveEscalation resolves the strict-widening judgment first; a non-widening request returns the effective mode immediately (no prompt, no downgrade — your rows 1–3), before any justification validation, so a blank or empty justification on an already-satisfied request cannot reject it.
2. Only a genuine widening request then requires a non-empty justification (requires a justification / non-empty sentence, both before any approver call — your rows 4).
3. The strict-wider grant, approval-channel checks, and outcome mapping are untouched (rows 5–8).
4. validateEscalationArgs is removed rather than reordered — the empty-string edge you flagged is exactly why: it rejected "" before the effective mode was known. The widening path now owns those checks, and a lone justification is ignored. tool-bash, tool-pwsh, and tool-fs all delegate on sandbox_permissions alone, so the Edit/Write path you reproduced is covered by the same change.

The branch's specs already exercise the core of your matrix (no-op grants including requested == effective with justification: undefined, widening with missing/blank reason failing closed with zero approver calls, and the full outcome mapping); folding in the remaining rows verbatim as a regression table is a small addition I'm happy to make if the team wants to take the branch.

Verified live on 0.1.1-rc.1 with the patch applied: the exact first-attempt Bash call that previously looped now completes with isError: false, and a genuine workspace-write → danger-full-access ask still prompts exactly once.