[Bug] Repeated sandbox_permissions causes subagent Bash/Write/Edit calls to fail repeatedly

[hytime]

Summary

A DSH subagent can repeatedly send sandbox_permissions with the same sandbox mode it already has (for example, requesting danger-full-access while the effective mode is already danger-full-access). The call then fails instead of being treated as an idempotent declaration, which can leave Bash, Write, or Edit work in a retry loop and effectively stall the task.

This is a DSH sandbox escalation Consumer issue, not a Claude Code permission or UI-plugin issue.

Reproduction

1. Start a sandboxed DSH agent with an effective mode of danger-full-access (the same behavior applies to other standing modes).
2. Invoke Bash, filesystem Write, or filesystem Edit with:

{
  "sandbox_permissions": "danger-full-access",
  "justification": ""
}

3. The request is routed through the escalation path and fails with an error equivalent to:

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

When the justification is missing or blank, validation can fail even earlier.

Expected behavior

A request whose sandbox_permissions equals the call's effective standing mode should be a no-op:

• execute using the existing standing policy;
• do not require or validate justification;
• do not request user approval;
• do not alter the strict widening rules for real escalation.

Root cause

The affected Consumers validate escalation arguments and enter the approval path before normalizing a repeated standing mode. The shared approveEscalation() correctly rejects equal and narrower modes, but Consumers need to short-circuit equal-mode declarations before calling it.

Scope

The affected Consumers are:

• packages/shell/tool-bash
• packages/shell/tool-pwsh
• packages/fs/tool-fs (write and edit through the shared sandbox controller)

The underlying approveEscalation() safety check and subagent approval: never design should remain unchanged; this does not require forwarding approval requests to the parent agent.

Fix and verification

A Consumer-level fix was implemented locally with regression coverage for missing, blank, and present justifications on repeated modes, plus downgrade and real-escalation safety cases.

Verified locally:

• 4 focused test files passed;
• 237 tests passed;
• pnpm run typecheck passed;
• pnpm run doc-sync passed;
• git diff --check passed.

The fix is intentionally limited to Consumer normalization and does not add permission persistence or parent-agent approval relay.

[argszero]

Verified against rc.8 source — your root-cause mapping is exact, and there are two structural points the fix needs to respect to fully deliver the expected behavior.

1. The equal-mode short-circuit must precede validateEscalationArgs, not just approveEscalation.

In all three consumers the arg-pairing validation runs before the standing policy is resolved:

• tool-bash — validateBashArgs → validateEscalationArgs (index.ts:67) at the top of execute
• tool-pwsh — index.ts:99, same shape
• tool-fs — FsSandboxController.resolvePolicy validates at sandbox.ts:88, resolves the standing policy at :89

So with justification: "" the call dies at invalid justification: expected a non-empty sentence (escalation.ts:58-60) before approveEscalation is reached. An equal-mode no-op that skips justification therefore has to be decided before validation, which means each consumer must resolve its standing policy first and then compare sandbox_permissions === policy.mode. That is a small reorder in all three places — and it is the one part a change inside approveEscalation alone cannot cover.

2. Suggest a shared normalization in dsh-sandbox rather than three hand-rolled checks.

escalation.ts's own doc says its job is "one home keeps the two families' approval ordering and verbatim error texts from drifting apart" — bash/pwsh already mirror each other under jscpd ignores. A fourth copied rule (equal-mode = declaration) becomes the third copy of a subtle check. A tiny shared helper keeps the semantics and the tests in one suite:

/** Equal-mode is a declaration, not an escalation: grants nothing, must not validate justification or prompt. */
export function normalizeEscalationMode(requested: string | undefined, effective: SandboxMode): SandboxMode | undefined {
  if (requested === undefined || requested === effective) return undefined // no escalation needed
  return requested as SandboxMode
}

Consumers then: resolve standing policy → normalizeEscalationMode(...) → undefined means execute under the standing policy (no validation, no approval) → otherwise validateEscalationArgs + approveEscalation unchanged. approveEscalation's strict-widening contract stays byte-for-byte intact, preserving the fail-closed property, and escalation.spec.ts gets the whole matrix (equal-mode with missing/blank/present justification, downgrade, real escalation, approver-not-called) in one place.

3. Why equal-mode is safe — and why approval: never needs it.

user-approval's 'never' policy is "never prompt anyone: every ask resolves 'rejected'" (user-approval/src/index.ts:90), and the shipped danger-full-access preset bundles sandbox: danger-full-access, approval: never (permission-presets). So a real escalation (wider mode) under never fails deterministically — either the widening throw or the rejection. The equal-mode no-op is the only sandbox_permissions value that can resolve without a human in the loop. This makes it more than idempotency sugar: it is the one path that makes the field functional at all under the never policy, which is exactly where the schema prose (tool-bash index.ts:263 "only valid as a one-shot retry of a command the sandbox just denied") breaks down into a retry loop. Treating equal-mode as a declaration completes the semantics instead of loosening safety.

Fix direction confirmed; the ordering point (short-circuit before validation, after policy resolution) is the piece I'd make sure the local fix and regression matrix cover.

[dxfq]

Facing same problem, will there be an official "fix" in next releases?