[Bug] 已是 danger-full-access 时重申同一模式被拒，导致非默认模型每次文件操作失败

[madbananana]

问题描述

会话的沙箱模式已经是 danger-full-access（用户显式设置的 Full access），但模型调用 write/edit/bash 工具时只要携带了 sandbox_permissions: "danger-full-access"，调用就会在执行前被拒绝：

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

关键点：

• 权限本身是够的（当前模式已是 danger-full-access，沙箱不限制任何操作）
• 报错来自升级校验（"请求模式必须严格更宽"），不是沙箱拒绝
• 用户配置了 Full access 仍看到权限类报错，误导性极强

复现步骤

1. 将会话权限预设切换为 danger-full-access（sandbox=danger-full-access, approval=never）
2. 使用非默认模型（任何未对 DSH 工具约定做专门调优的模型）
3. 让模型执行一次文件写入
4. 模型在调用中携带 sandbox_permissions: "danger-full-access"（schema 广告了该字段）
5. 调用被拒，报 "not strictly wider" 错误

默认模型通常遵守"仅在被拒后重试时携带该参数"的约定，因此不触发；非默认模型把该字段理解为"写文件的必需开关"，每次都携带，每次都失败。

根因

dsh-sandbox/lib/index.js 的 approveEscalation：

const WIDER_MODES = {
  "read-only": ["workspace-write", "danger-full-access"],
  "workspace-write": ["danger-full-access"]
};

async function approveEscalation(request, approval) {
  const { requestedMode: mode, effectiveMode, ... } = request;
  if (!(WIDER_MODES[effectiveMode] ?? []).includes(mode))
    throw new Error(`sandbox escalation to "${mode}" is not strictly wider ...`);
  ...
}

danger-full-access 不在任何 WIDER_MODES 表中（它是阶梯顶端），因此"重申当前模式"必然命中 !includes(mode) 分支而被拒绝。

辅助因素：dsh-tool-fs / dsh-tool-bash 的 schema 只要挂了沙箱后端就无条件广告 sandbox_permissions / justification 字段（描述还写着 "requires justification and user approval"），持续引导模型携带该参数。

影响

• 非默认模型在 Full access 会话中每次文件操作都失败，直到模型学会不携带该参数（或人工介入）
• 报错文案与 Full access 的实际状态矛盾，用户会误判为权限配置未生效
• 子代理场景同样受影响（审批策略固定为 never，无法通过升级绕开）

修复建议

P0（主修复）：approveEscalation 中将"请求模式 == 当前有效模式"视为 no-op，直接放行，不弹审批、不报错：

async function approveEscalation(request, approval) {
  const { requestedMode: mode, effectiveMode, justification, subject } = request;
  // No-op re-assertion of the call's current mode: widens nothing,
  // so grant the standing mode without an approval round-trip.
  if (mode === effectiveMode) return effectiveMode;
  if (!(WIDER_MODES[effectiveMode] ?? []).includes(mode))
    throw new Error(`sandbox escalation to "${mode}" is not strictly wider ...`);
  ...
}

安全论证：请求等于当前模式时权限零变化，不需要人类审批；fail-closed 语义不受影响——任何"请求模式 ≠ 当前模式"的路径（更宽要审批、更窄被拒）完全不变。

P1（引导，可选）：dsh-sandbox-policy 的 renderPolicyContext，danger-full-access 分支追加明确指令，例如 "Do not set sandbox_permissions on tool calls in this mode; it is already the widest."。注意不要按会话收窄 schema 广告（escalationModes）——schema 是 registry-global 的，按会话动态收窄不可行。

环境

• @deepseek-ai/dsh 0.1.0-rc.7（0.1.1-rc.2 中该逻辑未变）
• Windows + windows-acl 沙箱后端

[argszero]

Verified against rc.2 (HEAD b150a55) — this is the fourth independent report of the family (#3519 hytime → #4359 ZergZFZ → #4383 XY1998-debug, plus chenming0v0's WSL2 reproduction → #4412), and your root-cause is line-exact. Two corrections so the fix you propose lands family-complete:

1. mode === effectiveMode covers only half the failure surface

Your P0 no-op handles the equal-mode request. But #4383 documented a second, narrower-redundant case: sandbox_permissions: "workspace-write" while the effective mode is already danger-full-access also throws "not strictly wider" — and models that habitually attach the field pick both values. workspace-write !== danger-full-access, so mode === effectiveMode passes it through to the throw.

The complete predicate is the one the strict-wider check already uses:

// no-op whenever the requested mode is NOT strictly wider than the effective mode
if (!(WIDER_MODES[effectiveMode] ?? []).includes(mode)) {
  // equal or narrower → grant the standing mode; widens nothing, no approval round-trip
  return effectiveMode
}
// genuine widening → continue through the approval channel

Collapsing on !(WIDER_MODES[effectiveMode] ?? []).includes(requested) is safe: executing under the current effective mode grants nothing beyond what the call already holds. rc.2's WIDER_MODES (packages/sandbox/sandbox/src/escalation.ts:47-55) has no key for danger-full-access — ?? [] — which is exactly why every request fails there today.

2. The fix must sit before validateEscalationArgs, not only in approveEscalation

Your P0 lives inside approveEscalation, but all three consumers (tool-bash :67, tool-pwsh :99, tool-fs sandbox.ts:88) call validateEscalationArgs(args.sandbox_permissions, args.justification) at the top of their validate/execute paths, before escalation resolution runs. A same-mode request with an empty or omitted justification therefore dies earlier with "sandbox_permissions requires a justification" — approveEscalation is never reached. This is why the in-flight #4359 patch adds a shared normalizeEscalationMode(requested, effective) called before validation in all three consumers, with the equal-mode early return in approveEscalation kept as defense-in-depth. That review also caught a related fail-open regression (a lone justification must stay rejected, not silently swallowed), and the acceptance matrix now covers same-mode with/without justification, genuine widening, narrowing, and absent-mode.

3. Your P1 instinct is right — the schema description is the sharper lever

Your point about not narrowing the schema per-session matches rc.2's design comment on ESCALATION_TARGETS (escalation.ts:57-61) exactly: schemas are registry-global, effective mode is per-call. The model-facing surface worth updating is the schema description itself — currently "…requires justification and user approval", which is false for the no-op path and actively trains the habit you describe. The #4359 patch updates all three descriptions (tool-bash :264-266, tool-pwsh :275-277, tool-fs schemaFields()) to "escalating to a strictly wider mode requires justification and user approval; a retry at the call's current effective mode is accepted as a no-op", plus the JSDoc contract in escalation.ts. A prompt-context hint (your P1) is a fine complement, not a replacement.

Family status: 4 reports + 1 third-party reproduction, blueprint converged in #4359 (shared helper + 3-consumer reorder + equal/narrower no-op + contract text). This thread is the strongest signal yet that a maintainer patch is needed — hope it lands when the PR channel reopens.