[Bug] pwsh rejects a repeated sandbox mode with a blank justification, while bash and fs accept it

[Hal-Wang17]

Summary

On a session whose standing sandbox mode is already danger-full-access, a pwsh call that repeats that same mode with justification: "" is rejected:

Error: invalid justification: expected a non-empty sentence

Repeating the effective mode is a no-op escalation — approveEscalation returns immediately for mode === effectiveMode — and both sibling tools (bash, fs) special-case it before validating. pwsh validates first, so it rejects a call that would have been a no-op. On Windows pwsh is the only shell tool, so the failure is unconditional there.

Environment

• DSH Desktop, Windows 11
• @deepseek-ai/dsh-tool-pwsh@0.2.1-rc.2, dsh-tool-bash@0.2.1-rc.2, dsh-tool-fs@0.2.1-rc.2, dsh-sandbox@0.2.1-rc.2
• Session: permission preset danger-full-access, approval policy never
• Re-checked against master on 2026-11-02: still present for pwsh

Reproduction

{
  "command": "Get-Location",
  "description": "print the current directory",
  "sandbox_permissions": "danger-full-access",
  "justification": ""
}

→ Error: invalid justification: expected a non-empty sentence. The same argument shape is accepted by bash.

Why the call is a no-op

packages/sandbox/sandbox/src/escalation.ts:172-174

export async function approveEscalation<A, C>(request: EscalationRequest, approval: EscalationApproval<A, C>): Promise<SandboxMode> {
  const { requestedMode: mode, effectiveMode, justification, subject } = request
  if (mode === effectiveMode) return effectiveMode

Repeating the effective mode needs no approval and no reason. packages/fs/tool-fs/src/sandbox.ts:77-79 states the same rule in prose:

An omitted or repeated mode permits an omitted or blank justification; repeating the mode needs no approval.

Where the three tools disagree (master)

bash — packages/shell/tool-bash/src/index.ts:83-87

if (args.sandbox_permissions !== undefined && args.sandbox_permissions === effectiveMode) return
const justification = args.sandbox_permissions === undefined && args.justification?.trim() === ''
  ? undefined
  : args.justification
validateEscalationArgs(args.sandbox_permissions, justification)

fs — packages/fs/tool-fs/src/sandbox.ts:89-94 implements the same two rules (no-op early return + blank-justification normalization).

pwsh — packages/shell/tool-pwsh/src/index.ts:106-118

/* jscpd:ignore-start -- minimal mirror of dsh-tool-bash's validation and execute plumbing (Agent Note). */
function validatePwshArgs(args: PwshToolArgs): void {
  ...
  validateEscalationArgs(args.sandbox_permissions, args.justification)
}
/* jscpd:ignore-end */

No effectiveMode parameter and no blank-justification normalization. The call site makes the no-op rule impossible to implement as written — packages/shell/tool-pwsh/src/index.ts:502-505:

async execute(args: PwshToolArgs, exec) {
  validatePwshArgs(args)                     // ← validates before the mode is known
  const standingPolicy = resolveSandboxPolicy(exec)

Compare packages/shell/tool-bash/src/index.ts:480-481, which resolves first and validates second.

The jscpd:ignore markers say this is a deliberate mirror of bash's validation. That is presumably why the drift went unnoticed: bash gained two rules that the mirror never received.

Measured impact

One local workspace, 5 sessions over roughly two weeks: 29 failed tool calls with this exact message — 27 pwsh, 1 edit, 1 write. The edit/write ones are the same defect in the shipped 0.2.1-rc.2 bundle of tool-fs (master is already fixed there, so a release cut containing that fix leaves only pwsh).

Worst case observed: the model issued the identical pwsh call 6 times in a row. The message names neither the conflicting argument nor the remedy, so it kept editing description/command and left justification empty; only a repeat-call reminder that echoed the full arguments got it to add a sentence. Every failure costs a full model round-trip.

Suggested fix

Mirror bash — resolve the policy first, then validate with the mode:

const standingPolicy = resolveSandboxPolicy(exec)
validatePwshArgs(args, standingPolicy?.mode)

function validatePwshArgs(args: PwshToolArgs, effectiveMode: SandboxMode | undefined): void {
  ...
  if (args.sandbox_permissions !== undefined && args.sandbox_permissions === effectiveMode) return
  const justification = args.sandbox_permissions === undefined && args.justification?.trim() === ''
    ? undefined
    : args.justification
  validateEscalationArgs(args.sandbox_permissions, justification)
}

Optionally, make the error actionable — invalid justification: ... could name the paired argument and the remedy ("drop sandbox_permissions, or add a one-sentence justification"), which would cut the retries even before the ordering fix lands.