Bug: sandbox_permissions/justification break every tool call on Full access - sanitize no-op escalation requests

[praisesun-nus]

Hi team,

Bug summary
Under danger-full-access (Full access), models that reflexively fill optional fields (observed with GPT-5.6) pass sandbox_permissions + justification on almost every pwsh/bash/write/edit call. Because the escalation check requires the request to be strictly wider than the call's effective mode, every such call fails with::

Error: sandbox escalation to "workspace-write" is not strictly wider than this call's current "danger-full-access" mode
Error: invalid justification: expected a non-empty sentence

The tool schemas are registry-global (built once per composition) while the effective mode is per-session, so a session already at the widest mode is still offered the escalation fields - a Full access session cannot ever widen anything, so any filling of these fields is guaranteed to error.

Proposed fix (safety-neutral)
Treat "requests that cannot widen anything" as a no-op instead of an error:

1. approveEscalation - if the effective mode is already danger-full-access, return the standing mode without prompting (ignoring any target, including the reflexive first-enum-entry workspace-write, and any blank justification).
2. Same-mode request under a confined mode (requested == effective) is also a no-op: it widens nothing and never prompts.
3. Everything else stays verbatim: a different, wider request under read-only/workspace-write still goes through the strict widening check, the approval chain, and the closed fail texts; unknown/invalid effective modes still fail closed.

Changes span packages/sandbox/sandbox/src/escalation.ts plus the tool call sites (tool-bash, tool-pwsh, tool-fs), about 170 lines with tests (151 cases pass locally, including host/client typecheck).

A ready branch exists on my fork for review:

• fork: praiseSun-nus/deepseek-harness
• branch: sandbox-noop-escalation (1 commit, based on master @ b150a55)
• commit: 56fac8d319 fix(sandbox): treat no-op sandbox escalation requests as ignorable

Happy to rewrite it as a PR the moment external PRs are accepted, or adapt the diff to your preferred form. Thanks for this great harness!

[denial123789]

这个故障与 rc.2 的两层设计吻合：schema 是 registry-global，effective mode 是 per-call；因此 Full Access Session 仍可能看到 escalation enum，但 WIDER_MODES["danger-full-access"] 为空，任何 target 都无法通过 strict-wider 检查。

我认为 no-op 方向能解决 liveness，但需要补一个实现细节和一个安全表述：

1. validateEscalationArgs() 在各 tool call site 中先于 approveEscalation()。如果模型给了 blank justification，只改 approveEscalation() 仍然到不了 no-op 分支。补丁必须明确由哪一层先识别 standing-mode no-op，并同时消费这两个 optional fields。
2. 它不会扩大 authority，但会把原本 fail-closed 的 malformed authority input 变成 ordinary execution。因此最好称为“可观察的兼容性策略”，并保留 raw received args 或 bounded marker，而不是完全静默 sanitize。

建议至少固定以下行为：

• Full Access + 任意已知 target：不降级、不 prompt、不创建 grant，按 standing Full Access 恰好执行一次；
• Workspace Write + same mode：按 standing mode 执行一次；
• Read Only/Workspace Write + genuinely wider target：仍要求非空 justification、approval 和 one-call grant；
• unknown/narrower target、invalid effective mode：继续 fail closed；
• Bash、PowerShell、write、edit 全部走同一决策表；
• denied/cancelled/unavailable/agent-less 的真实 escalation 结果保持不变。

另外，Session-aware schema 可以减少模型误填，但会让不同 Session 的 tool schema identity 改变并影响 provider prefix cache；它是另一项权衡，不应与 execution-time no-op 混成一个修复。

我把完整 decision table、调用顺序和 regression gates 加到了现有 sandbox runbook：
https://github.com/sandbaseai/deepseek-harness-handbook/blob/main/docs/en/troubleshooting/sandbox-denied-vs-unavailable.md

[Evuse]

How can i understand if you write in chinese? Write in english please

[PerryLink]

注：本条评论原文因编码问题曾显示为乱码，已重建为可读版（2026-09-07）。

关于「宽权限 sanitize 掉」的讨论（来自 dsh-permission-rules 的实测）：在 Full access 环境下「默认 escalation 空」时，规则匹配会被 sanitize 吞掉，需要显式放行：

# .dsh/rules.yml -- 把 escalation 匹配显式化到 ask，避免 strict-wider 吞掉
- pattern: "**"
  action: allow
  when: { escalation: null }

补充这个 bug：sanitize 对 no-op escalation 的处理有空洞，导致显式配置在部分路径上失效；建议排查时先看 effective mode 的最终判定，再看 call 上下文是否真的带上了 escalation 字段，两者不一致就是它。

[weijiafu14]

A cross-transport datapoint that supports the "sanitize/ignore, don't throw" direction — the materialization itself is wire-presentation-dependent, so the host will keep seeing both shapes:

Same model family (GPT-5.6-sol, ChatGPT-subscription OAuth), driven through a different transport configuration (pi2dsh's Codex route on stock 0.1.1-rc.2): the write call came out with exactly ["file_path","content"] — no sandbox_permissions, no justification materialized, validation passed, file on disk (evidence). The deep isolation of why the other path materializes optionals is in #1149 (and upstream earendil-works/pi#8105): the Codex responses wire presents declared-but-optional top-level properties in a way the model then fills.

Consequence for this thread: since materialization depends on how the transport presents the schema — not on the model being broken — Full-access hosts will receive redundant sandbox_permissions from some transports indefinitely. That makes your report's implied fix the right one: a non-widening sandbox_permissions under an already-wider mode should be dropped/no-op'd (it's semantically redundant, not an escalation), never thrown on. Throwing turns a benign wire artifact into "every tool call fails".