Sandbox escalation error when session is already at danger-full-access

[XY1998-debug]

Sandbox escalation error when session is already at danger-full-access

Summary

When a session's effective sandbox mode is danger-full-access, the bash, pwsh, and filesystem tools still advertise sandbox_permissions + justification parameters in their tool schema. If the model attaches these parameters (which it does frequently), every such call fails with:

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

or, for a narrower redundant request:

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

This wastes tokens on failed tool calls and retry loops, especially in subagent scenarios where the child session inherits the parent's danger-full-access override via source: 'delegation' events.

Root Cause

Three components share the same pattern:

1. Schema is registry-global, effective mode is per-call

escalationModes is determined once at plugin load time:

// tool-bash/src/index.ts (line 198), tool-pwsh/src/index.ts (line 199)
const defaultMode = ctx.shell.sandboxMode
const escalationModes: readonly SandboxMode[] = defaultMode === undefined ? [] : ESCALATION_TARGETS

ESCALATION_TARGETS is always ['workspace-write', 'danger-full-access'] regardless of the session's current effective mode. The source comment in escalation.ts (lines 37-41) explains this is intentional — schema is registry-global, effective mode is per-call, so the enum can't be narrowed without stranding sessions that were switched to a narrower mode.

2. validateEscalationArgs runs before effective mode is resolved

In validateBashArgs / validatePwshArgs:

// tool-bash/src/index.ts line 67, tool-pwsh/src/index.ts line 99
validateEscalationArgs(args.sandbox_permissions, args.justification)

This is called at the top of validateXxxArgs, before resolveSandboxPolicy(exec) runs in the execute path. So even if the escalation request is redundant, an empty or missing justification throws first:

invalid escalation: sandbox_permissions requires a justification

3. approveEscalation has no redundant-request tolerance

In escalation.ts (lines 162-163):

if (!(WIDER_MODES[effectiveMode] ?? []).includes(mode as SandboxMode)) {
  throw new Error(`sandbox escalation to "${mode}" is not strictly wider than this call's current "${effectiveMode}" mode`)
}

WIDER_MODES has no entry for 'danger-full-access', so WIDER_MODES['danger-full-access'] is undefined, falling back to []. Any mode the model requests will fail the check.

4. Subagent inheritance amplifies the problem

child-agent.ts (lines 199-204) captures the parent's explicit sandbox override and seeds it into the child as source: 'delegation'. The child's approval policy is also pinned to 'never'. So a subagent of a danger-full-access parent:

• Inherits danger-full-access as its effective mode
• Cannot get approval for any escalation (policy is 'never')
• Still sees sandbox_permissions in the tool schema
• Any attempt to use it → guaranteed failure

Affected Files

File | Package -- | -- packages/sandbox/sandbox/src/escalation.ts | @deepseek-ai/dsh-sandbox packages/shell/tool-bash/src/index.ts | @deepseek-ai/dsh-tool-bash packages/shell/tool-pwsh/src/index.ts | @deepseek-ai/dsh-tool-pwsh packages/fs/tool-fs/src/sandbox.ts | @deepseek-ai/dsh-tool-fs

Additional coverage:

• Composition default differs from session effective mode
• bash, pwsh, fs behave identically
• Model-visible schema (not just internal resolver)
• Approval prompt count (redundant requests produce zero prompts)
• Background and foreground execution paths

[argszero]

Verified against rc.2 (HEAD b150a55) — this is the third independent report of the same family: #3519 (hytime, 2026-08-20, same-mode sandbox_permissions) → #4359 (ZergZFZ, full fix mid-flight) → this report. Your root-cause analysis is accurate line-by-line, and your second error string exposes a gap the in-flight #4359 patch does not yet cover — details below.

1. rc.2 confirms every claim

• WIDER_MODES (packages/sandbox/sandbox/src/escalation.ts:47-55) has keys only for read-only and workspace-write; WIDER_MODES['danger-full-access'] is undefined, so ?? [] makes every request fail the includes at approveEscalation (escalation.ts:157-164) when the effective mode is already the maximum. Exact.
• The schema stays registry-global by design: ESCALATION_TARGETS (:57-61) is the closed target vocabulary with the deliberate comment that cutting the enum to wider-than-default would strand sessions switched to a narrower mode. So the model will keep attaching sandbox_permissions at danger-full-access — tolerant handling of redundant requests is the only robust fix, not schema narrowing.
• validateEscalationArgs runs at tool-bash/src/index.ts:67 / tool-pwsh/src/index.ts:99, before resolveSandboxPolicy in the execute path — a redundant request with a missing justification throws requires a justification first, as you note.
• Delegation: captureDelegatedPolicyOverrides (packages/subagent/subagent/src/child-agent.ts) seeds the child's sandboxMode from the parent's override and pins approval to 'never' — a subagent of a danger-full-access parent hits every failure mode with zero escape.

2. The gap: #4359's patch collapses only the equal-mode case

ZergZFZ's fix (#4359) adds normalizeEscalationMode(requested, effective) returning undefined for absent or equal-mode requests (called before validateEscalationArgs in all three consumers), plus a mode === effectiveMode early return in approveEscalation as defense-in-depth.

That fixes your first error string (danger-full-access requested at danger-full-access → normalized away → plain execution). But your second error string is the narrower case: workspace-write requested while the effective mode is danger-full-access. workspace-write !== danger-full-access, so the patch's normalize passes it through → approveEscalation still throws not strictly wider. The missing-justification variant of the same request also still throws at validation.

The redundant-request tolerance must therefore use the same predicate as the strict-wider check: collapse whenever !(WIDER_MODES[effectiveMode] ?? []).includes(requested) — i.e. equal or narrower — not just equal. This is safe: executing under the current effective mode grants nothing beyond what the call already holds; genuine widening still normalizes to the requested mode and goes through the approval channel. Concretely, normalizeEscalationMode should share the WIDER_MODES table (single source of truth for "what may this call escalate to"), and the approveEscalation early return stays as defense-in-depth for any non-normalized path.

3. Regression matrix addition

Your "additional coverage" list (model-visible schema, approval prompt count → zero for redundant, background/foreground) maps onto the 11-check matrix already posted in #4359. Worth adding the narrower-redundant rows — workspace-write at effective danger-full-access, with and without justification — to that matrix so the family closes completely; today's patch would fail both.

[chenming0v0]

Additional reproduction from a Linux/WSL2 installation using the published CLI:

• @deepseek-ai/dsh@0.1.1-rc.2
• Node.js v24.15.0
• Linux 6.6.87.2-microsoft-standard-WSL2
• custom llm-pi-ai provider with api: openai-responses
• session preset: sandbox: danger-full-access, approval: never
• model: custom gpt-5.6-sol

A simple request to run gh auth status/GitHub API calls did not reach the shell successfully. The model repeatedly treated sandbox_permissions/justification as necessary tool arguments. Omitting sandbox_permissions led it to report that the field was required; adding sandbox_permissions: "danger-full-access" then hit the exact failure tracked here:

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

The installed DSH implementation confirms that the source bash schema only marks command and description as required (@deepseek-ai/dsh-tool-bash/lib/index.js, parameter registration); sandbox_permissions and justification are optional there. However, both escalation fields remain model-visible whenever a sandboxing executor is mounted, even when the effective session mode is already danger-full-access and approval is never. This makes a redundant model-generated escalation request poison an otherwise ordinary command.

This reproduces the issue outside a delegated subagent and with an OpenAI Responses-compatible custom provider. The robust fix should preserve fail-closed behavior for genuine widening while treating same-mode (and, as noted above, otherwise non-widening) requests as no-op execution under the standing policy. It should also keep the malformed lone-justification case rejected.

[nokkies]

Same defect as #4359 (the strictly-wider check can never accept the mode the call already holds, and danger-full-access has no wider mode). Fixed in our fork by treating a same-mode request as an idempotent grant - a one-line guard before the strictly-wider check returns the effective mode; no prompt, no error, identical to omitting the parameter. Semantics discussed on #4359.