建议：同模式的 sandbox_permissions 请求应该直接放行，而不是报错

[ywsldxk]

问题

部分模型习惯每次调 pwsh/bash 都带上 sandbox_permissions，大概是被训练成"显式声明权限"了。当会话本来就是 danger-full-access 时，这种无害请求会直接报错：

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

单用户本地环境默认就是这个配置，所以很常见。模型带着同样的参数反复重试，工具反复拒绝，一次 turn 就这么耗掉了。

根因

approveEscalation（packages/sandbox/sandbox/src/escalation.ts）的"严格更宽"检查会拒绝任何不在 WIDER_MODES[effectiveMode] 里的模式。WIDER_MODES 没有 danger-full-access 的条目，因为它已经是最高级。结果 full-access 会话请求 full-access 就报"not strictly wider"。

但这个请求根本不是升级——调用方只是要求在当前模式下执行。没有权限增益，不该走到审批，也不该 fail-closed。

建议改法（改动很小，不影响安全）

requestedMode 等于 effectiveMode 时直接放行，真正的升级仍然走严格更宽检查 + 审批：

export async function approveEscalation(request, approval) {
  const { requestedMode: mode, effectiveMode, justification, subject } = request
  // 同模式请求：没有权限增益，直接放行
  if (mode === effectiveMode) return mode
  // 真正的升级：必须严格更宽，再走审批
  if (!(WIDER_MODES[effectiveMode] ?? []).includes(mode)) {
    throw new Error(`sandbox escalation to "${mode}" is not strictly wider than this call's current "${effectiveMode}" mode`)
  }
  // ... 原有审批流程不变
}

安全性

• mode === effectiveMode 授予的就是调用方当前已有的权限，danger-full-access → danger-full-access 不改变进程能做什么。
• read-only → workspace-write、workspace-write → danger-full-access 这些真升级，仍然要过严格更宽检查 + 审批。
• 请求更窄的模式（如 workspace-write → read-only）依然被拒。

为什么要改

模型的工具调用行为差异很大，不是所有模型都能遵守"没被拒绝就别传 sandbox_permissions"。我们测的几个流行模型（GPT 系列）会在大多数调用里带上这个字段，默认配置下每次调用都硬失败，报的错还让人摸不着头脑。接受同模式请求，把这个无操作变成静默通过，至少不会白白烧重试。

[zoahdev]

核验通过（对照 main HEAD 99f6f02 rc.7）——根因准确，补丁方向正确，但有两个增量点值得补进提案。

1. 根因确认。 packages/sandbox/sandbox/src/escalation.ts:22-28 的 WIDER_MODES 只有 read-only → [workspace-write, danger-full-access] 和 workspace-write → [danger-full-access]，没有 self 条目（escalation.spec.ts:24 明确 expect(WIDER_MODES['danger-full-access']).toBeUndefined()）。approveEscalation（escalation.ts:150-157）在审批前先做严格更宽检查：(WIDER_MODES[effectiveMode] ?? []).includes(mode)，同模式必落 ?? [] 分支 → 抛 "not strictly wider"，且从不询问用户。danger-full-access → danger-full-access 在生产可达（ESCALATION_TARGETS 枚举含该值，escalation.ts:35-38）。

2. 增量点一：现有测试会破。 tests/escalation.spec.ts:83-89 现在把 read-only → read-only（同模式！） 当"非更宽拒绝"的钉住用例：approveEscalation(req({ requestedMode: 'read-only' }))（effectiveMode 默认 'read-only'）期望抛 not strictly wider。按你的改法 mode === effectiveMode → return mode，这个断言直接翻绿失败。测试需要同步更新：把非更宽夹具改成真正更窄/不可比的对（如 effective danger-full-access + requested workspace-write，spec 里已有该例），再加两个同模式放行用例（workspace-write→workspace-write、danger-full-access→danger-full-access）并断言不经过 approver（沿用 seen 数组的现有模式）。

3. 增量点二：工具层 validation 在 approveEscalation 之前，只改 escalation 覆盖不到"不带 justification"的模型。 三个强制执行族在入口先跑 validateEscalationArgs（tool-bash index.ts:67、tool-pwsh index.ts:99、tool-fs sandbox.ts:88），它要求 sandbox_permissions 与 justification 必须成对（escalation.ts:43-51）。只传 sandbox_permissions 不带理由的模型会在更早处报 sandbox_permissions requires a justification，根本到不了你的补丁。如果目标是"同模式无操作静默通过"，更完整的位置是工具层执行时：先解析 effectiveMode，requestedMode === effectiveMode 时整条跳过 escalation 路径（不校验 pairing、不询问）；approveEscalation 内的同模式短路是这条链的兜底（防御直接调用者）。如果只想做最小改动，则同模式仍需 justification 这一点要写进 README/错误提示，否则模型会在 validation 层继续撞墙。

4. 安全性评估同意。 同模式授予的就是当前已有权限；更窄请求（schema 层 ESCALATION_TARGETS 已排除 read-only）与真升级（strictly-wider + 审批）路径不变。

综合：你的补丁 + 测试更新 + （可选）工具层同模式短路，三件套就是完整 PR。需要的话我可以补一份带回归测试的完整 diff。

[zoahdev]

补上了：cherry-pick-ready 分支 fix/escalation-same-mode-pass-through（基于 main HEAD 99f6f02）已在 fork 上：

https://github.com/zoahdev/deepseek-harness/tree/fix/escalation-same-mode-pass-through

内容 = 提案补丁 + 测试更新（同模式放行 ×3 用例 + 非更宽夹具改为真正更窄/不可比的对）。验证（2026-08-19，Windows / Node 24 / pnpm 11）：

• vitest run packages/sandbox/sandbox/tests → 3 files / 19 tests passed（escalation.spec.ts 12/12）；
• 全量 host tree tsc -b tsconfig.host.json typecheck 通过（lefthook pre-push 自动执行）。

工具层同模式短路（跳过 validateEscalationArgs 的那半）我留在分支外——它需要在 validation 时就有 effectiveMode 上下文，值得单独评估，防止把不相关改动塞进一个最小修复。待 PR 通道开放时可 cherry-pick。