[Bug] Same-mode sandbox_permissions hard-errors instead of running — loops GPT-family models

[Tannnnhauser]

On a workspace-write (or danger-full-access) session, a tool call whose sandbox_permissions requests a mode the session already has (same or narrower) fails instead of just running. GPT-family models (e.g. gpt-5.6-sol) speculatively attach this field on ordinary calls and then loop on the two errors below for the whole turn — on danger-full-access they never recover.

Error: sandbox escalation to "workspace-write" is not strictly wider than this call's current "workspace-write" mode
Error: invalid justification: expected a non-empty sentence   (when the reason is emptied)

No argument set passes both. The operation needed no escalation — writing in the workspace is already permitted.

Expected: same-mode → run normally; narrower → reject as a downgrade (not "missing justification"); wider → approval unchanged.

Env: DSH 0.1.1-rc.2, gpt-5.6-sol via azure-openai-responses.

[PerryLink]

Confirmed, and still live on master (c291e79). Your root-cause claim is correct, with one nuance.

What the code does today:

• approveEscalation throws for ANY non-strictly-wider request, same-mode included:
  packages/sandbox/sandbox/src/escalation.ts:162-164
  if (!(WIDER_MODES[effectiveMode] ?? []).includes(mode)) throw ... "is not strictly wider than ..."
• The argument-pairing validator runs first and also throws on a blank justification:
  packages/sandbox/sandbox/src/escalation.ts:51-61 (validateEscalationArgs)
  So there really is no argument combination that lets a same-mode call through — exactly the loop you saw.
• Both tool families route through it: pwsh/bash (packages/shell/tool-pwsh/src/index.ts:347-352) and write/edit
  (packages/fs/tool-fs/src/sandbox.ts:87-108).
• This is partly intentional: the spec test at packages/sandbox/sandbox/tests/escalation.spec.ts:84
  ("a non-widening request fails closed with its own text and never asks") pins the throw.

Why it still bites: the schema advertises the full enum ['workspace-write','danger-full-access'] whenever a confining
backend is mounted (escalation.ts:41), independent of the session's effective mode — so on a danger-full-access session
the model is invited to send values that can never win. That schema/execution mismatch is the real defect.

Workarounds today: (1) if the session already has the mode you need, the model must omit the field — a system-prompt or
preset persona note ("do not send sandbox_permissions when the session is already at/above that mode") helps GPT-family
models; (2) a truly confining setup (read-only default) keeps every genuine widening going through approval, which at
least terminates; (3) upstream fix direction (proposed in #4976/#4763, safety-neutral): treat mode === effectiveMode
(and narrower-than-current under danger-full-access) as a no-op returning the current mode, keeping strict-widening +
approval unchanged. Not fixed in 0.1.5-rc.x as of this checkout.

[JohnXu22786]

Confirmed as a concrete Bash manifestation of this issue on Fedora Linux with DSH 0.1.5-rc.2 and a local web profile using the Responses API. On a new conversation already running with danger-full-access, the model may send sandbox_permissions: "danger-full-access" together with justification: "" (or omit justification). Bash validates the empty/missing justification before it can recognize that the requested mode is already effective, producing: invalid justification: expected a non-empty sentence. Existing conversations often work because they do not emit the redundant fields. Local fix: defer escalation-argument validation until the effective mode is known; return the current mode immediately for same-mode requests, and keep non-empty justification plus approval required for real workspace-write -> danger-full-access escalation. I applied this to Bash and the filesystem edit/write path and verified the service after restart.

[PerryLink]

Thanks for the Fedora repro — a very useful concrete confirmation. The
invalid justification: expected a non-empty sentence you hit is
validateEscalationArgs (packages/sandbox/sandbox/src/escalation.ts:59), which
runs before approveEscalation ever compares requested vs effective mode
(escalation.ts:162-164), so a same-mode call dies on the empty justification
instead of being recognized as a no-op — exactly the loop reported here.

Your local fix order is the right one: resolve the effective mode first,
short-circuit same-mode requests (return the current mode), and only then run
argument-pairing validation and approval for real widenings. Two things worth
carrying into any upstream change:

1. The pinned spec packages/sandbox/sandbox/tests/escalation.spec.ts:84
   ("a non-widening request fails closed with its own text and never asks")
   currently asserts that same-mode requests throw "not strictly wider" — the
   test must change together with the behavior.
2. Keep the fail-closed text for genuinely narrower requests unchanged; that
   wording is part of the model-facing denial vocabulary both tool families
   teach.

Verified still unfixed on master c291e79 as of today. This is tracked in
#4976 / #4763 — posting your patch description there is the best route to get
it in (the repo doesn't merge external PRs yet, per CONTRIBUTING.md, so a
discussion write-up is how fixes land).