Bug/Design: approveEscalation 在 effectiveMode 为 danger-full-access 时拒绝同级/降级升级导致模型死锁循环

[yltx]

问题背景

在基于 @deepseek-ai/dsh-sandbox 与各执行工具（@deepseek-ai/dsh-tool-pwsh、@deepseek-ai/dsh-tool-bash、@deepseek-ai/dsh-tool-fs）的编排场景中，当运行环境、会话或 Standing Policy 已处于最高权限 danger-full-access 时，模型调用工具（如 pwsh 或 edit）偶发会附带冗余权限升级参数（例如再次申请 danger-full-access，或在上下文飘移时传了较低的 workspace-write）。

异常表现

当前 packages/sandbox/sandbox/src/escalation.ts 中的校验逻辑如下：

if (!(WIDER_MODES[effectiveMode] ?? []).includes(mode)) {
  throw new Error(`sandbox escalation to "${mode}" is not strictly wider than this call's current "${effectiveMode}" mode`)
}

由于 WIDER_MODES['danger-full-access'] 定义为空数组 []，任何升级请求进入 approveEscalation 时：

• 请求 danger-full-access：判定为非 strictly wider，直接抛出 sandbox escalation to "danger-full-access" is not strictly wider than this call's current "danger-full-access" mode；
• 请求 workspace-write：判定为降级，同样抛错拒绝。

在实际执行中，该错误抛出后被模型捕获并触发 repeat-tool-reminder。由于模型已经处于 full access，它再次调用工具时依然容易携带默认的写权限参数，导致连续十几轮 not strictly wider 报错死锁，无法继续执行正常任务。

预期行为

当 effectiveMode 已经是系统预设的最高权限 danger-full-access 时，进一步的 escalation 请求属于已被完全覆盖的冗余操作（NOOP / Idempotent），不应 fail-closed 阻断调用，而应直接放行并保持 danger-full-access 模式执行，避免阻断合法工作流。

建议修复方案

在 approveEscalation() 检查入口增加早返回（并建议对未知的 effectiveMode 保持 fail-closed）：

export async function approveEscalation(
  request: EscalationRequest,
  approval: EscalationApproval,
): Promise<SandboxMode> {
  const { requestedMode: mode, effectiveMode, justification, subject } = request

  // 当当前调用已处于最高权限模式时，任何升级/冗余请求均已得到完全覆盖，直接放行
  if (effectiveMode === 'danger-full-access') {
    return 'danger-full-access'
  }

  // 保持 fail-closed：未知的 effectiveMode 严格判定失败
  const allowed = WIDER_MODES[effectiveMode]
  if (allowed === undefined || !allowed.includes(mode)) {
    throw new Error(
      `sandbox escalation to "${mode}" is not strictly wider than this call's current "${effectiveMode}" mode`,
    )
  }
  // ... 后续常规审批流程
}

同时，工具端参数解析（如 tool-pwsh / tool-bash 的 validateEscalationArgs）在 Standing Policy 为 danger-full-access 时，也可相应放宽对冗余参数成对性（如空白 justification）的硬性阻断，避免模型因模板参数残留而报错。

[argszero]

我在同步到 0.1.5 线的 master（c291e7961a）上逐条核对了源码，结论是：你诊断的失败模式成立，但它有两个独立触发点，而当前实现里"没有任何合规的调用形状能成功"——这比报告描述的更严重；同时建议的补丁会同时踩到两个坑。 下面全部是可复现的源码坐标。

一、比报告更严重：不是"偶发"，是"结构性不可能"

WIDER_MODES（packages/sandbox/sandbox/src/escalation.ts:28-31）只有两个键：

export const WIDER_MODES: Record<string, readonly SandboxMode[]> = {
  'read-only': ['workspace-write', 'danger-full-access'],
  'workspace-write': ['danger-full-access'],
}

danger-full-access 连键都没有，所以 :162 的 WIDER_MODES[effectiveMode] ?? [] 退化成空数组，任何 sandbox_permissions 取值都命中 !includes 并抛 not strictly wider。

关键在于：工具在 danger-full-access 下依然对外广告这两个字段。tool-bash/src/index.ts:192 只看 ctx.shell.sandboxMode === undefined 来决定是否广告（:258-267），而 :191 的 defaultMode 取的是执行器默认模式，不是本次调用的生效模式。所以"默认 workspace-write 的 composition + 会话切到 full access"这一组合下，模型看到 enum、照工具描述去用，然后必然失败。

更彻底的是：WIDER_MODES['danger-full-access'] 为空意味着升级和降级全被拒——sandbox_permissions: 'workspace-write' 和 'danger-full-access' 抛的是同一条错。所以此刻没有一个合法取值能通过。这不是"冗余参数偶发附带"，而是"只要模型按广告行事就一定死锁"。

顺带一个会放大死锁的细节：packages/bundle/base/cordis.patch.yml:227 把 danger-full-access 预设配成 approval: 'never'。于是抛错发生在 :162，根本走不到审批环节——用户连拒绝的机会都没有，只看到一串 not strictly wider。这正是死锁循环能持续十几轮的原因。

二、报告的补丁会踩两个坑

坑 1：置顶早返回会把"降级"也放行。 你的写法在 effectiveMode === 'danger-full-access' 时无条件 return 'danger-full-access'，包括 requestedMode: 'workspace-write' 的降级请求。而 packages/sandbox/sandbox/tests/escalation.spec.ts:89-90 已经把这个行为钉死了：

await expect(approveEscalation(req({ requestedMode: 'workspace-write', effectiveMode: 'danger-full-access' as never }), spy))
  .rejects.toThrow(/not strictly wider/)

同一个测试用例在 :91 还断言 expect(seen).toEqual([]) —— 即"非加宽请求绝不能唤起审批"。置顶早返回会同时破坏这两条断言。正确形状是先判等值（mode === effectiveMode → no-op 返回），等值之外照旧复用严格加宽判定，这样降级仍然 fail-closed、且仍不提示用户。

坑 2：光这一行还不够，还有两个前置闸门。

• validateEscalationArgs（escalation.ts:51-61）要求 sandbox_permissions 与 justification 成对且非空。模型残留模板参数时往往带着空 justification，于是在 :58 就抛 expected a non-empty sentence，走不到 approveEscalation。这个校验在 tool-bash/src/index.ts:330（validateBashArgs 内），拿不到 exec、也拿不到生效模式——所以"按模式放宽配对性"在工具层没有可用的输入。
• 工具 schema 是注册表全局的（escalation.ts:23-26 的注释正是在讲这件事：schema 是 registry-global，生效模式是 per-call truth），所以也没法按会话切 enum。

三、一个可能更好的落点：schema 投影，而不是放宽校验

:33-41 的 ESCALATION_TARGETS 已经明确否决了"cutting the enum down to the modes wider than the composition's DEFAULT"（理由是会把生效模式更窄的会话困死）。但按"本次调用的生效模式"投影恰好同时满足两边：

• 当前为 danger-full-access → 广告面里没有可升级目标，也就没有"可选用的合法值"这个错误前提——模型不再被诱导去填 sandbox_permissions，死锁前提直接消失；
• 当前窄于 full access → 照旧广告（:38-39 那条关切不受影响，因为投影按 per-call 生效模式，不按 composition 默认）。

代价是 schema 里那个 enum 从常量变成按调用计算。如果不想动投影，退一步也要在执行点做等值归一，两层互为保险。

四、插件面：能做一半，但不建议做

因为我要给"这缺口该不该走插件"一个明确答复：PreToolDecision（packages/core/tools/src/index.ts:581-584）的 allow 分支只携带 { kind: 'allow' }，docstring（:574-580）原文写着 "Input rewriting is excluded because arguments are already logged and presented"。所以插件无法从 sandbox_permissions/justification 里抹掉那些字段。

唯一可及的窄用法是 kind: 'deny'：在 tools/pre-execute 里侦测到"生效模式已是 full access 且本调用携带 sandbox_permissions"时拦下并给出纠正反馈，让模型重发一次干净调用。代价是每次意图执行要多烧一个往返，而且 deny 同时吞掉合法调用（插件在工具层难以可靠判定"这是冗余"还是"模型真的想升级"）。结论：这属于 core 面，插件只是受害者，已归档为 upstream-fix 候选。

五、一句话

你的判断对，且比报告更硬：当前 full access 下任何 sandbox_permissions 都必然抛错，而工具仍在广告这些字段。建议的补丁方向正确但形状要改——等值走 no-op（先于严格加宽判定）、降级留给 fail-closed，再补上"配对性校验在模式为 full access 时不可达"这层；escalation.spec.ts:24 已经断言 WIDER_MODES['danger-full-access'] 为 undefined，所以别去给这个键补值（那是把降级合法化），要走等值分支。

[yltx]

非常感谢 @argszero 如此详尽且一针见血的源码级梳理与边界分析！

完全赞同你的结论与重构方向：

1. 等值归一（No-op）代替单边置顶：
   确实不应在 effectiveMode === 'danger-full-access' 下无条件放行所有模式。改为：
   s // 等值请求视为幂等 no-op，直接保留原生效模式 if (mode === effectiveMode) { return effectiveMode }
   这样同级请求（danger-full-access -> danger-full-access）平滑放行，而任何降级请求（如 workspace-write）依然会干净地落入后续的 !(WIDER_MODES[effectiveMode] ?? []).includes(mode) 并抛出
   ot strictly wider，完全吻合并保全了 escalation.spec.ts:89-91 中“降级必须 fail-closed 且绝不唤起审批”的既有契约。

2. Schema 动态投影 + 执行点归一的双保险：

   • 从根源上看，per-call 依据生效模式动态投影 schema，在已经是 danger-full-access 时直接抹去可升级枚举，消除了诱导模型产生幻觉/冗余填充的前提；
   • 在执行层配合等值归一，即便模型因跨会话记忆或强模板残留带入了同级参数，也能安全吸收。

期待 upstream-fix 的推进与合入！