【BUG】Sandbox same-mode escalation dead-ends with invalid justification / not strictly wider when approval is disabled

[Armourwind]

问题类型 Issue type: 【BUG】

Summary

Tool calls that request the sandbox mode already in force hit a fail-closed dead end instead of running, when the session's standing mode is danger-full-access and the approval policy is never (approval prompts disabled). The model gpt-5.6-sol reproduced this repeatedly on the DeepSeek Harness repo while editing files.

Exact errors observed

• Error: invalid justification: expected a non-empty sentence
• Error: sandbox escalation to "danger-full-access" is not strictly wider than this call's current "danger-full-access" mode

Environment

• Model: gpt-5.6-sol (this report is filed from a session running that model)
• Session file policy: danger-full-access (the standing mode already in force)
• Approval policy: never (approval prompts disabled / auto-rejected)
• Tools affected: bash, pwsh, write, edit (any tool that advertises sandbox_permissions)

What happens

When the standing sandbox mode is already danger-full-access, the model's tool calls sometimes still carry sandbox_permissions: "danger-full-access" (e.g. after an escalation hint or by generation habit). Because the request targets the mode already in force, it widens nothing — but the tool layer could not tell that:

• Without a justification the call is rejected as invalid escalation: sandbox_permissions requires a justification.
• With a blank/whitespace justification the call is rejected as invalid justification: expected a non-empty sentence.
• With a real justification the call reaches the approval channel and is rejected by approveEscalation as sandbox escalation to "danger-full-access" is not strictly wider than this call's current "danger-full-access" mode.

None of these paths ever executes the command or file operation. In a never-approval session there is no human to approve anything, and retrying without the field does not reliably help because generation keeps re-supplying sandbox_permissions. Calls of the same tools that happen to omit the field succeed, so the failure looks like a tool-schema defect when the schema and parameter transmission are actually correct.

How to reproduce (complete steps)

Code under test. Any commit that predates the fix — the fix is not merged into the official repo, so upstream master reproduces it. Confirmed on master @ d347e70390 (dsh 0.1.3-alpha.1); the pre-fix code is also visible at commit cd5ef81481 (the fix branch's base).

Prerequisites. A DSH session whose standing sandbox mode is danger-full-access and whose approval policy is never (approval prompts disabled), running model gpt-5.6-sol.

Repro 1 — deterministic, no model needed (test harness)

Run the pre-fix regression suites; the old assertions pass precisely because they pin the dead-end texts:

pnpm vitest run packages/shell/tool-bash/tests/tools.spec.ts \
  packages/shell/tool-pwsh/tests/tools.spec.ts \
  packages/fs/tool-fs/tests/tools.spec.ts \
  packages/sandbox/sandbox/tests/escalation.spec.ts

• tool-bash / tool-pwsh — "rejects injected escalation … non-widening escalation without prompting": a bash call carrying sandbox_permissions: 'workspace-write' under a standing workspace-write session override is asserted to fail with not strictly wider and never prompt.
• tool-fs — "rejects the escalation argument pairing (one field without the other)": a same-mode write carrying only sandbox_permissions is asserted to fail with sandbox_permissions requires a justification.
• escalation.spec / the bash generic-producer suite — a blank justification: ' ' is asserted to fail with invalid justification: expected a non-empty sentence.

Repro 2 — live session, direct tool calls (no model needed)

In a session already running under danger-full-access with approval never, issue these three calls in sequence (they mirror exactly what the model does when it retries):

#	Tool call	Result
1	write(file_path: "a.txt", content: "x", sandbox_permissions: "danger-full-access") — no justification	Error: invalid escalation: sandbox_permissions requires a justification
2	same, retry with justification: "" (empty string, as generated when there is nothing to justify)	Error: invalid justification: expected a non-empty sentence
3	same, retry with justification: "the file is already inside the permitted project"	Error: sandbox escalation to "danger-full-access" is not strictly wider than this call's current "danger-full-access" mode

bash / pwsh behave identically (they fail at validateBashArgs / validatePwshArgs and approveEscalation); write / edit fail at FsSandboxController.resolvePolicy. Every attempt returns isError and no command or file mutation ever executes.

Repro 3 — model-driven (the original report, gpt-5.6-sol)

1. Start a DSH session with model gpt-5.6-sol in the repo checkout; set the session standing mode to danger-full-access (session override sandbox/mode) and approval policy to never.
2. Ask it to make a file edit inside the workspace.
3. Observe the transcript: the first write/edit call carries sandbox_permissions: "danger-full-access" (the model re-supplies the field even though the session already runs in that mode — e.g. after seeing the escalation hint). It is rejected per Repro 2.
4. gpt-5.6-sol retries: dropping the field works (the file changes), but the next tool call re-attaches sandbox_permissions and is rejected again; empty-justification retries produce invalid justification: expected a non-empty sentence, justified retries produce not strictly wider…, and with approval never there is no approval prompt to rescue the non-widening path.
5. Because calls that omit the field succeed while calls that carry it never do, the failure reads as a tool-schema defect; the schema and parameter transmission are actually correct — the validator just has no concept of "already effective".

Root cause

The escalation validator had no concept of the call's standing (already-effective) sandbox mode. validateEscalationArgs in packages/sandbox/sandbox/src/escalation.ts validated the sandbox_permissions ⇔ justification pairing unconditionally, and approveEscalation rejected any target that was not strictly wider than the effective mode. A same-mode request is not an escalation at all, but it was validated and approved as one.

Fix we applied locally

fix/sandbox-escalation-same-mode (commit add0182fc5, plus test follow-up 9a564d48f9) resolves this: a request for the mode already in force is treated as a no-op escalation that runs directly under the standing policy — no justification required, no approval asked, nothing widened.

• validateEscalationArgs gains an optional effectiveMode argument and returns immediately when sandboxPermissions === effectiveMode.
• tool-bash, tool-pwsh, and tool-fs now resolve the standing policy before validating and short-circuit same-mode requests past the approval channel.
• Strictly wider requests still require a non-empty justification plus approval; narrower requests still fail closed; a malformed empty-string sandbox_permissions is still rejected by the JSON-Schema enum layer.

Suggested upstream fix mirrors that branch. Happy to open a PR against the official repo if maintainers prefer (the fork branch is fix/sandbox-escalation-same-mode).

[Armourwind]

Targeted note for the maintainers who own this path. The fix is a straight short-circuit, so the core hunk is inlined below for direct lifting (CONTRIBUTING says external PRs are not accepted, so I am not opening one).

Why this matters: the failing configuration (standing danger-full-access + approval policy never) is the normal unattended/autonomous-agent setup. Under it, every tool call that carries sandbox_permissions dead-ends — three distinct error paths, none of which ever executes the operation, and retries cannot recover. Same-tool calls that happen to omit the field succeed, which makes the failure look like a tool-schema defect when the schema and parameter transmission are correct. Reproduced repeatedly on master @ d347e70390 (dsh 0.1.3-alpha.1) with gpt-5.6-sol.

Root cause: validateEscalationArgs (packages/sandbox/sandbox/src/escalation.ts) validates without knowing the mode already in force, and approveEscalation rejects any target that is not strictly wider — so a request for the current mode (which widens nothing and should simply run) is forced through the justification + approval checks.

Core fix — full change: validateEscalationArgs gains an effectiveMode parameter and same-mode requests short-circuit; tool-bash / tool-pwsh / tool-fs resolve the standing policy before validating and run same-mode requests past the approval channel. Strictly wider requests still require a non-empty justification and approval; narrower requests still fail closed.

diff --git a/packages/sandbox/sandbox/src/escalation.ts b/packages/sandbox/sandbox/src/escalation.ts
index 5cc180fe2b..2bde6c9087 100644
--- a/packages/sandbox/sandbox/src/escalation.ts
+++ b/packages/sandbox/sandbox/src/escalation.ts
@@ -44,11 +44,21 @@ export const ESCALATION_TARGETS: readonly SandboxMode[] = ['workspace-write', 'd
  * Validate the escalation argument pairing a tool schema cannot express:
  * `sandbox_permissions` and `justification` travel together — an approval
  * prompt without a reason, or a reason driving nothing, is a malformed ask —
- * and the justification must be a non-empty sentence.
+ * and the justification must be a non-empty sentence. A request for the mode
+ * already in force is NOT an escalation: it widens nothing, so it passes
+ * without a justification and never reaches the approval channel.
  * @param sandboxPermissions - the raw `sandbox_permissions` argument, if given.
  * @param justification - the raw `justification` argument, if given.
+ * @param effectiveMode - the call's standing sandbox mode, when a confining
+ *   executor is mounted; lets a same-mode request short-circuit the pairing
+ *   checks.
  */
-export function validateEscalationArgs(sandboxPermissions: string | undefined, justification: string | undefined): void {
+export function validateEscalationArgs(
+  sandboxPermissions: string | undefined,
+  justification: string | undefined,
+  effectiveMode?: SandboxMode,
+): void {
+  if (effectiveMode !== undefined && sandboxPermissions === effectiveMode) return
   if (sandboxPermissions !== undefined && justification === undefined) {
     throw new Error('invalid escalation: sandbox_permissions requires a justification')
   }

Reference implementation: fork branch fix/sandbox-escalation-same-mode (commit add0182fc5; clean cherry-picks 47666f876d + 9047c41f1f on current master), regression coverage added across the shared validator and the three enforcing families, 233 focused tests green. Happy to post the full 11-file diff or split per tool family on request.

（中文摘要：sandbox_permissions 请求目标等于当前生效模式时，在 approval=never 会话里必然死胡同——根因是 validateEscalationArgs 不知道"已生效模式"，把零加宽请求误当升级走审批。修复只需把同模式请求短路放行，严格加宽仍要求 justification 与审批。）

@imccyu @CreatixChu

[argszero]

Verified against master d347e70390 — your root cause is accurate, and this is the 8th report of the same-mode escalation family, which makes your proposed fix the right shape by prior consensus rather than a one-off patch.

Source confirmation (master):

• packages/sandbox/sandbox/src/escalation.ts:51-61 — validateEscalationArgs validates the sandbox_permissions ⇔ justification pairing unconditionally, with no knowledge of the standing mode. It runs at tool-layer argument-validation time (tool-bash/src/index.ts:64-66), i.e. before the standing policy is even consulted — the escalation path resolves standingPolicy.mode only later (tool-bash ~:205-222; tool-fs/src/sandbox.ts:88 validates, then :97 calls approveEscalation with policy.mode).
• escalation.ts:162 — approveEscalation rejects any target not strictly wider per WIDER_MODES (:28-31). Note the table has rows only for read-only and workspace-write as effective modes — there is deliberately no row for danger-full-access, because nothing is wider than it. That is correct as a backstop, but it means a same-mode request under full access always fails the widening test; and since the check runs before the approval channel (:165+), approval policy is irrelevant — the throw happens first.

Your three error paths map exactly: no justification → :53 (pairing check, before the mode is known); blank → :59; same-mode with a justification → :162. None ever executes.

On the fix shape: resolving the standing policy before validating and short-circuiting sandboxPermissions === effectiveMode is the right layer — and it is what closes all three paths, because a short-circuit inside approveEscalation alone would only cure the with-justification case (the other two die earlier in validateEscalationArgs). One ordering note for the port: keep the composition guard reachable. In a composition without a sandboxing executor, escalationModes.length === 0 and standingPolicy is undefined (tool-bash ~:213-219) — today an unadvertised sandbox_permissions call still reaches that guard and gets "not available in this composition". If the same-mode bypass only fires when a confining executor is actually mounted (a resolved policy exists), non-sandboxing compositions behave exactly as before — pass effectiveMode into validation only then.

Family context: #5611 is the closest sibling — full-access state serialized with escalation fields still attached dies the same double failure (empty justification → validation; non-empty → not-strictly-wider). Earlier #3519/#4359/#4383/#4412/#5570/#5588 (plus #4976/#4990) cover the equivalent-declaration idempotency axis. What your report adds is the tool-layer ordering fact — validation fires before the mode is known — which is precisely why the fix belongs in the tool layers (or in validateEscalationArgs gaining an effectiveMode parameter), not only in approveEscalation.

On the PR offer: upstream collaboration here is Discussions + plugins only (Issues/PRs are disabled), so the in-thread diff plus the fork reference (fix/sandbox-escalation-same-mode, commit add0182fc5) is the liftable channel — the maintainers tagged above can cherry-pick from it. For anyone hitting this today: calls that omit the field run fine under the standing full-access mode, so dropping sandbox_permissions is the working retry; a same-mode reassertion is a harmless no-op semantically and should not dead-end the turn.