openai-responses models fill optional sandbox_permissions with the current mode, bricking all bash calls

[cloudgg82-blip]

Environment

• DSH CLI: 0.1.2-alpha.4 (macOS, installed via npm under nvm)
• Model: GPT-class models through a custom provider using the openai-responses protocol (pi-ai adapter)
• Session sandbox policy: workspace-write

Symptom

After switching the session model to a GPT-class model, every bash tool call is rejected before execution with:

Error: sandbox escalation to "workspace-write" is not strictly wider than this call's current "workspace-write" mode

Timeline from one session's durable log (session.jsonl.zstd, request/header + rejected tool results):

14:31  model switched to gpt/* (openai-responses provider)
14:32:57 - 14:35:58  11 consecutive bash calls rejected (all with the error above)
14:39:09  12th rejection (inside a subagent sharing the same model route)
14:43  model switched back to glm/*  →  the exact same command succeeds on the first try

None of the rejected commands ever executed — they all fail at parameter validation. The model also never learns to drop the field from the error message: it retries the identical arguments ~12 times.

Root cause

The bash tool schema exposes an optional sandbox_permissions field whose intended semantics are "a one-shot retry requesting a wider mode after a real sandbox denial" (the description says Only valid as a one-shot retry of a command the sandbox just denied).

However, GPT-class models (openai-responses protocol) facing a task that writes into the workspace proactively fill this optional field with workspace-write — which equals the session's current mode. The harness correctly validates that a same-level value is "not strictly wider" and rejects the call outright.

Models on other protocols (glm via openai-completions) never populate this optional field, which is why the problem only appears on the openai-responses route. Subagents inheriting the same model route hit the same wall.

So it is an interaction between model behavior (filling optional permission fields) and a strict validation policy (hard-reject on same-level), which bricks all tool usage for the whole session with no self-recovery.

Suggestions (any one would fix it)

1. Graceful strip: when sandbox_permissions equals the current mode (i.e., not strictly wider), strip the field, log a warning, and execute the command normally instead of rejecting it. A same-level value is a no-op request, not an escalation attempt — it carries no additional risk.
2. Hide the field from the model-visible schema: only surface sandbox_permissions in the retry context after a real [sandbox: file access denied] denial.
3. At minimum, make the rejection message explicitly instruct the model to omit the field and retry (current wording does not teach the model anything actionable — it retries identical arguments).

Option 1 seems strictly better for robustness: the escalation path (wider mode requested) still goes through the approval flow, while the no-op case stops bricking sessions.

Reproduction

1. Configure a custom provider with api: openai-responses and a GPT-class model.
2. Start a session with sandbox policy workspace-write.
3. Ask the agent to run any command that writes inside the workspace (e.g., a script run with a project workdir).
4. Observe every bash call rejected with the error above; switching to a glm model makes the identical command succeed immediately.