【BUG】edit 工具调用层错误地把同级权限当成了权限升级请求

[shuzixin]

是的，这基本可以判定为一个 bug，具体在 文件工具与 sandbox 权限参数的衔接层，而不是 Full Access 策略本身。

预期行为应是：

当前文件策略 = danger-full-access
普通 edit/write
=> 直接执行
=> 不传 sandbox_permissions

实际行为却是：

当前文件策略 = danger-full-access
普通 edit/write
=> 自动附带 sandbox_permissions = danger-full-access
=> 被误判为“请求升级到同级权限”
=> 在执行文件操作前失败

关键证据是错误发生在工具参数处理阶段：

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

文件系统甚至没有机会尝试写入，所以不是文件路径、权限位或 Full Access sandbox 后端拒绝。

更具体地说，可能存在以下一个或两个问题：

• sandbox_permissions 被错误地作为文件工具的常规必填参数处理，而不是仅用于“sandbox 实际拒绝后的重试”；
• 工具执行器没有判断“请求权限是否已经等于当前生效权限”，直接把同级权限当成非法升级。

修复方向应是：

if (requestedPermission === currentPermission) {
  // 直接执行，不走 escalation
}

或者更彻底地：

普通文件工具调用不生成 sandbox_permissions；
只有收到真实 sandbox denial 后，重试调用才附带该字段。

另外，之前我在调用中主动传入这个参数，也放大了问题；按照官方文档和当前运行时规则，Full Access 下不应主动传递它。这个问题值得在 Harness 的文件工具参数适配或工具执行管线中加一个回归测试，覆盖：

danger-full-access + approval never + edit/write in workspace

预期结果应为成功写入，而不是同级权限升级错误。

[denial123789]

查了 rc.2 的 packages/sandbox/sandbox/src/escalation.ts 和对应单测后，这里需要修正一个关键点：

read-only < workspace-write < danger-full-access

sandbox_permissions 的语义不是“声明本次当前权限”，而是请求一次性、严格更宽的模式。因此：

• read-only -> workspace-write / danger-full-access 有效；
• workspace-write -> danger-full-access 有效；
• danger-full-access -> danger-full-access 按设计无效，并且应在审批和执行前拒绝。

所以错误本身反而能证明文件操作尚未执行；但修复不应是：

if (requestedPermission === currentPermission) execute();

这会把一个格式错误的 authority request 静默降级成普通调用，削弱审计语义。正确的普通 Full Access 调用确实是不带 sandbox_permissions 和 justification；下一步应追踪这两个字段由模型原始 tool call、客户端转换、插件 wrapper，还是手工调用插入。

另一个容易误判的地方是：rc.2 的工具 Schema 可以在挂载的 executor 默认受限时公开完整升级枚举，而 Session 生效模式可变成 Full Access；Schema 里看得到字段，不表示每次都应填写，执行时的 strict-wider 检查才是权威。

建议回归矩阵至少覆盖：

1. Full Access + 普通 edit/write：成功；
2. Full Access + 同级 escalation：无审批、无效果、明确拒绝；
3. workspace-write + 工作区内普通写：成功；
4. workspace-write + Full Access escalation：仅获批后执行；
5. approval never 不得把非法 escalation 转成普通执行。

我把 denial、SANDBOX_UNAVAILABLE、普通操作失败和 invalid escalation 四类信号及证据路径整理在这里，并固定到了 rc.2 源码与单测：
https://github.com/sandbaseai/deepseek-harness-handbook/blob/main/docs/en/troubleshooting/sandbox-denied-vs-unavailable.md

[nokkies]

你的诊断是对的，而且这个修复已经存在了 —— 你命中的是一个已知缺陷（#4359 / #4383），修复方式和你提的第一个方案一字不差。

packages/sandbox/sandbox/src/escalation.ts 里 approveEscalation 的第一个判断就是：

// A same-mode request is already satisfied: the call runs at that mode with
// or without the parameter, so it is granted idempotently — no prompt, no
// audit row, nothing widened. Models habitually re-request the mode they
// already hold, and erroring turned that habit into a hard failure on
// `danger-full-access` sessions, where NO strictly wider mode exists
// (upstream #4359 / #4383).
if (mode === effectiveMode) return effectiveMode

同级请求直接幂等放行，不提示、不写审计、不加宽，然后才轮到严格加宽检查。注释里点出的正是你观察到的那件事：在 danger-full-access 会话下，根本不存在更宽的模式，所以把「重复请求当前模式」判为非法升级，等于把模型的一个常见习惯变成硬失败。

所以：

• 如果你还能复现，说明你跑的构建早于这个修复。请贴一下 @deepseek-ai/dsh-sandbox 的实际版本 —— 你原文只写了现象没写版本，而这决定了你是遇到老问题还是遇到了一个新的问题。
• 如果换到带修复的版本仍然复现，那就是另一回事了，值得单独开一条：说明失败发生在 approveEscalation 之前的某个环节，而不是这个判断里。

关于你提的第二个方向

普通文件工具调用不生成 sandbox_permissions；只有收到真实 sandbox denial 后，重试调用才附带该字段。

这个方向本身是对的，但要注意它管不到你这个症状：sandbox_permissions 是模型填的工具参数，不是工具执行器生成的。也就是说，harness 这边没法「不生成」它 —— 能做的只有在收到时正确处理，而这正是上面那个幂等分支做的事。文档里建议 Full Access 下不要主动传，是给模型/使用者的指引，不是运行时可以强制的约束。

换句话说：能被代码保证的那一半已经在了，剩下的一半只能靠不把它当错误。

你最后提的回归测试建议是好的，值得单独确认一下是否已覆盖：danger-full-access + approval never + 工作区内 edit/write，期望写入成功而不是同级升级报错。

[shuzixin]

当前根版本：@deepseek-ai/dsh-root@0.1.1-rc.2
@deepseek-ai/dsh-sandbox 实际版本：0.1.1-rc.2
已执行 git pull --ff-only，远端代码已是最新：Already up to date
不知道这个版本是否已经修复了这个已知缺陷？