Bug: sandbox escalation rejects non-widening sandbox_permissions, causing tool-calling error spam with non-DeepSeek / custom models

[lyz-728]

Bug: sandbox escalation rejects non-widening sandbox_permissions, causing tool-calling error spam with non-DeepSeek / custom models

(posted as a Discussion because Issues are disabled on this repo)

Summary
When the agent model passes sandbox_permissions on a call that is not strictly wider than the session's current effective sandbox mode — or passes it with an empty justification — the sandbox escalation gate rejects the whole tool call. Custom / weaker models (e.g. gpt-5.6-luna through an OpenAI-completions gateway) pass sandbox_permissions speculatively or redundantly, so switching to such a model surfaces these as tool-calling failures by the dozen.

Environment
DeepSeek Harness Web GUI, Windows host
Custom model via an OpenAI-completions gateway, or any non-DeepSeek model
Sandbox mode workspace-write (default) or danger-full-access
Observed errors
From packages/sandbox/sandbox/src/escalation.ts → approveEscalation:

sandbox escalation to "" is not strictly wider than this call's current "" mode
invalid justification: expected a non-empty sentence
Both repeat many times in one conversation when the model over-uses sandbox_permissions.

Why it matters
Tool-calling regression with custom models. The schema advertises sandbox_permissions (enum workspace-write / danger-full-access) whenever a confining executor is mounted, but the effective mode is per-session. A session already at danger-full-access is still offered sandbox_permissions: danger-full-access; when the model passes it, the request is redundant and the call fails with not strictly wider — which reads to the user as "full access did not take effect".
Approval stalls. A widening request under the ask policy with no answerer can leave the call with TOOL_OUTCOME_UNKNOWN.
A non-widening request can never grant anything beyond the standing mode, so rejecting it punishes the model for an argument that has no effect — with no security benefit.

Suggested fix
Treat a request that is not strictly wider than the effective mode as ignored: approveEscalation returns the effective mode and the call runs at the standing mode, prompting no one. Validate justification only on the strictly-wider path. The strict-wider check at execution (not the schema enum) remains the safety boundary — nothing beyond the effective mode is ever granted.

A working patch is available on request (13 files: escalation.ts, tool-fs/tool-bash/tool-pwsh tool layers, their tests, and READMEs).

Repro
Start a session in workspace-write mode with a custom model.
Ask the model to work on files; it tends to pass sandbox_permissions: "workspace-write" (equal to the standing mode) or an empty justification.
Observe the two errors above repeated across tool calls.

[rafalePOP]

Additional reproducible downstream failure observed on Windows 11 with DSH Desktop 2.0.2 / Harness 0.1.1-rc.2, using an AgentTeams delegated Codex gpt-5.6-sol worker under workspace-write.

The delegated worker invoked a read-only pwsh Git status command with sandbox_permissions: "workspace-write". The same non-widening escalation error was returned 88 times across three turns. There was also one empty-justification error and one rejected danger-full-access attempt.

More importantly, stopping the affected AgentTeams workers caused additional session corruption:

1. The task remained in_progress while its member became idle.
2. A stopped subagent’s closing notice included an unresolved tool-call block without a corresponding tool result.
3. Every subsequent parent turn failed with HTTP 400:
   No tool output found for function call ...
4. An empty assistant/message was then recorded at step 0 without a matching step/start, causing:
   token meter: assistant/message ... has no matching step/start event
5. Session compaction subsequently failed with the same token-meter error.

Suggested safeguards in addition to treating same-mode escalation as a no-op:

• Add a circuit breaker for repeated identical tool failures.
• When a subagent is interrupted, never splice an unresolved tool call into the parent context; emit a cancelled/synthetic tool result or plain text instead.
• Make token metering and compaction tolerate or discard orphaned assistant events.
• Reconcile AgentTeams task/member state after interruption.

No project file operation was reached before the loop; the failure occurred in tool dispatch and session recovery.