Bug: same-mode sandbox_permissions is rejected as an invalid escalation

[iamzhaoxin]

Summary

A tool invocation can fail before execution when its adapter serializes sandbox_permissions equal to the call's effective sandbox mode.

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

This makes normal Bash and filesystem calls fail in a session already running at danger-full-access.

Expected behavior

When requestedMode === effectiveMode, treat the request as use of the standing policy and execute without an approval prompt. Actual upward escalations must continue to require approval; narrower or invalid modes must remain rejected.

Minimal fix

In approveEscalation, before the strict-widening check:

if (mode === effectiveMode) return effectiveMode;

Then retain the existing strict-widening check.

Regression tests requested

1. Omitted sandbox_permissions executes under the standing policy.
2. sandbox_permissions === effectiveMode executes without approval.
3. read-only -> workspace-write and workspace-write -> danger-full-access still request approval.
4. A narrower or unrelated requested mode remains rejected.

Impact

This can block normal plugin development and routine tool calls. It can also prevent a running DSH process from repairing itself because the same validation rejects the Bash or file-edit operation needed to apply a fix.

[argszero]

Reproduced and confirmed — the bug sits exactly at packages/sandbox/sandbox/src/escalation.ts:162.

Why it throws on a same-mode request:

const { requestedMode: mode, effectiveMode, justification, subject } = request
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 only contains the upward ladder keys (read-only, workspace-write):

export const WIDER_MODES: Record<string, readonly SandboxMode[]> = {
  'read-only': ['workspace-write', 'danger-full-access'],
  'workspace-write': ['danger-full-access'],
}

So when effectiveMode === 'danger-full-access', WIDER_MODES['danger-full-access'] is undefined — the ?? [] swallows it into an empty array, and .includes('danger-full-access') returns false even though requestedMode === effectiveMode. The result is the exact "not strictly wider than this call's current 'danger-full-access' mode" throw you hit. This is not a map gap (the ladder deliberately has no upward entry for the top mode; the test pins expect(WIDER_MODES['danger-full-access']).toBeUndefined() at escalation.spec.ts:24), it is a missing same-mode branch.

Your minimal fix is the right shape and matches the design intent in the JSDoc ("a non-widening request never prompts a human" — and a truly non-widening request here is the equal one, which should simply proceed under the standing policy):

if (mode === effectiveMode) return effectiveMode

I'd add one guard so the equality branch doesn't silently accept a malformed same-mode ask: keep validateEscalationArgs (the sandbox_permissions/justification pairing) ahead of approveEscalation — both enforcing families already do this (tool-bash/src/index.ts:212 and tool-pwsh/src/index.ts:230 call it in the resolver), so an equality short-circuit inside approveEscalation cannot bypass the "justification required with sandbox_permissions" rule.

Regarding the regression tests you listed, they map cleanly onto the existing spec at escalation.spec.ts (the approveEscalation describe block). Suggested additions:

• requestedMode === effectiveMode returns the mode without calling the approver (assert the approver sink stays empty, mirroring the existing "never asks" test at line 84-92).
• read-only -> workspace-write and workspace-write -> danger-full-access still ask (the existing "grants" test already covers the read-only→workspace-write path).
• A narrower/unrelated mode still rejects (the existing "non-widening" test covers read-only requested under read-only effective, and workspace-write requested under danger-full-access).

One design note worth flagging for whoever merges this: the same-mode grant should be advertisement-independent. The schema ESCALATION_TARGETS = ['workspace-write', 'danger-full-access'] is advertised whenever the composition confines, and a session whose effective mode is danger-full-access still sees the fields. Today the serializer rejects the sandbox_permissions it accepts — so this fix also unblocks the "self-repair" path you mentioned (a danger-full-access session running a Bash/file call that passes its standing mode back now executes instead of throwing). Good find.

[kittimzhe]

@argszero — agree on the diagnosis. Implemented it, with one refinement to keep read-only excluded, on kittimzhe/deepseek-harness@fix/same-mode-sandbox-escalation (commit de65e72):

if (mode === effectiveMode && (ESCALATION_TARGETS as readonly string[]).includes(mode)) {
  return effectiveMode
}

So workspace-write and danger-full-access re-affirmed at the same effective mode run under the standing policy without prompting (the read-only floor and a true downgrade still hit the strict-widening throw — the existing "non-widening" test stays green). The target check uses the static vocabulary, not per-call advertisement, so it lines up with your advertisement-independent point.

escalation.spec.ts gains one case — "re-affirming an advertised same-mode target runs without prompting" (both targets resolve, approver never called). vitest run packages/sandbox/sandbox/tests/escalation.spec.ts → 12 passing, pre-push typecheck green.