Full access tool calls still serialize sandbox escalation fields and fail before execution

[NingYuanLee]

Summary

When a DSH Web GUI session uses Full access (danger-full-access + approval policy never), model-generated pwsh, edit, and write calls still serialize the escalation-only fields sandbox_permissions and justification. The calls are rejected before execution even though the session already has the highest permission.

Reproduction

1. Open a DSH Web GUI session on Windows.
2. Select Full access, or run /permission danger-full-access.
3. Ask the agent to run PowerShell or edit a file.
4. Observe that the emitted tool call still includes:

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

Actual behavior

An empty justification fails with:

invalid justification: expected a non-empty sentence

A non-empty justification fails with:

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

The same behavior occurred in the lead session and delegated/subagent sessions. Repeated retries can form loops, making Full access less usable than workspace-write + ask.

Expected behavior

When the standing mode is danger-full-access:

• Ordinary calls omit sandbox_permissions.
• justification is also omitted because no escalation is requested.
• The tool executes directly under the standing policy.
• Both fields are serialized only for the documented one-shot retry after a real sandbox denial.

Workaround

Switch the current session to workspace-write + ask, then request danger-full-access as a wider one-shot escalation. This works but is cumbersome and contradicts the purpose of Full access.

Suggested fix

1. Keep both escalation fields truly optional in the model-visible and transport schemas.
2. Strip them from ordinary calls when the standing mode is already Full access.
3. Consider normalizing an accidentally supplied same-mode request as non-escalating without opening approval.
4. Add a real Web GUI tool-round regression test that selects Full access and verifies pwsh/edit reaches execution with both fields absent.
5. Verify delegated and durable team agents receive the corrected behavior after permission-preset changes.

Environment

• DSH Web GUI
• Windows
• File policy: danger-full-access
• Approval policy: never

[argszero]

This is the third+ report of what's become a well-documented family (earlier: #3519, #4359), and it's still open in master — I verified the exact mechanism. Your diagnosis is correct; the key is the ordering, and the "not strictly wider" message you see is actually a red herring for the empty-justification case.

Verified against master (76fda72979) — two independent failure points, ordered:

packages/sandbox/sandbox/src/escalation.ts:

1. validateEscalationArgs (:51, throw at :59) runs first in each Consumer's tool-execute path. With an empty justification, it throws invalid justification: expected a non-empty sentence — before any escalation comparison even happens. So your "empty justification fails" is the validation gate, not the width check.
2. Then approveEscalation (:157, throw at :162-163): if (!(WIDER_MODES[effectiveMode] ?? []).includes(mode)) → not strictly wider. danger-full-access has no wider entry in WIDER_MODES, so a same-mode request is always rejected here.

So the empty-justification path dies at gate #1; a non-empty just-different justification survives #1 but dies at #2. Both are the same root defect: the Consumer's flow validates sandbox_permissions/justification against a requested escalation before resolving whether this call actually needs one under the standing policy.

The real bug is ordering, not the width check. The tool-execute path should be:

resolve standing policy.mode
→ if sandbox_permissions is absent OR === effective mode  → no escalation requested, execute directly (skip validation + approval)
→ else (a real widening request) → validateEscalationArgs + approveEscalation (fail-closed, unchanged)

This is exactly what normalizeEscalationMode(requested, effective) does — returns undefined for absent/equal mode so the caller skips validation+approval entirely. It was designed for this family (converged in the earlier threads) but is not merged upstream (confirmed: 0 matches for normalizeEscalationMode in packages/). The 3 Consumers (tool-bash, tool-pwsh, tool-fs sandbox.ts — the only validateEscalationArgs callers) all need the same reorder.

Why this matters beyond convenience: your repro uses Full access = danger-full-access + approval never. Under approval: never, a true escalation is impossible (every ask resolves to "rejected" — no channel). So the only way sandbox_permissions can succeed under Full access is as a same-mode no-op. Making same-mode a no-op isn't just idempotency sugar — it's the only success path for never-approval Full-access sessions. You're right that the workaround (fall to workspace-write + ask, then one-shot escalate) is cumbersome and against the point of Full access.

Suggested fix is sound and matches the converged blueprint:

• Keep both fields optional in model-visible/transport schema.
• Strip them when the call doesn't request an escalation (absent/equal-to-standing mode).
• Sequence the consumers: resolve policy → normalize → skip validation+approval on no-op; real widening keeps the unchanged fail-closed path.

I'm happy to put together the exact normalizeEscalationMode helper + the 3-consumer reorder as a reference diff if that helps move this upstream.

[NingYuanLee]

Thanks so much for offering to do that! I completely agree with your approach on this.

Yes, please go ahead and share the reference diff (or patch) whenever you have it ready. Having the exact helper and the 3-consumer reorder laid out explicitly will definitely make it easier for everyone to review and get the normalizeEscalationMode change merged upstream smoothly.

We'll take a close look once you post it. Thanks again for driving this!

[NingYuanLee]

I implemented and verified the reference patch locally against the current 0.1.2-alpha.5 tree. The final shape is slightly more explicit than normalizeEscalationMode: the shared helper normalizes the complete request so the pairing rules remain centralized.

Shared normalization (dsh-sandbox)

export function normalizeEscalationRequest(
  requestedMode: string | undefined,
  justification: string | undefined,
  effectiveMode: SandboxMode | undefined,
): NormalizedEscalationRequest | undefined {
  if (requestedMode !== undefined && requestedMode === effectiveMode) return undefined
  validateEscalationArgs(requestedMode, justification)
  if (requestedMode === undefined || justification === undefined) return undefined
  return { requestedMode, justification }
}

This ordering gives the intended matrix:

• both fields absent: ordinary call;
• target equals the effective mode: standing-policy no-op, including missing or blank justification;
• target is different: validate the pair, then apply the existing strictly-wider and approval checks;
• justification without a target: still rejected;
• narrower or unknown targets: still rejected before approval;
• an injected target in a non-confining composition: still rejected.

approveEscalation() also starts with if (mode === effectiveMode) return effectiveMode as defense for direct callers. Consumers still need the normalizer because a missing/blank reason otherwise fails before approveEscalation() is reached.

Three Consumer changes

tool-bash, tool-pwsh, and tool-fs/src/sandbox.ts now use the same sequence:

resolve standing policy
→ normalizeEscalationRequest(..., standingPolicy?.mode)
→ no normalized request: execute with the unchanged standing policy
→ normalized request: approveEscalation before execution

The raw tool/call arguments are not mutated, so replay and audit retain exactly what the model emitted. Only execution semantics are normalized.

The model-visible schema descriptions now say that a strictly wider request requires justification and approval, while the current effective mode is an approval-free no-op. Lower targets are deliberately not normalized: silently running a call under broader standing authority than the supplied target names would be surprising and would weaken least-authority semantics.

Verification

• Shared tests cover absent, same-mode, wider, narrower, malformed, and direct-approval paths.
• Bash/pwsh/fs Consumer tests cover same-mode calls with missing and blank reasons, no approval event, standing-policy execution, genuine widening, orphan justification, narrowing, and non-confining rejection.
• Focused suite: 152 tests passed, with focused per-file coverage passing.
• Real Web recording remains the provider-authored baseline. A keyless replay patch adds sandbox_permissions: danger-full-access without justification to the Full access write response, then the real Web composition asserts successful disk output and no approval/asked event. Web replay: 3/3 passed.
• Full build and repository typecheck passed.
• After restarting dsh web, I also verified the live Host directly: same-mode pwsh with a blank justification executed, and same-mode write with a blank justification created a temporary file without opening approval; the file was then removed.

This closes the empty-justification ordering failure and the later not strictly wider failure without changing genuine escalation authorization.