Bug: sandbox escalation error occurs when current mode is already danger-full-access

[Mazureqwq]

# Bug: Incorrect Sandbox Escalation Error When Current Mode Is Already `danger-full-access`

## 问题描述

当前 DeepSeek Harness 会话已经处于：

```text
sandbox mode: danger-full-access
approval policy: never

但是调用 pwsh、write 或 edit 工具时，工具层仍然把请求识别为 Sandbox 权限升级，并报错：

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

当请求改为：

sandbox_permissions: "workspace-write"

则报错：

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

这个问题会导致当前会话无法继续执行普通的文件写入、文件编辑和 shell 命令。

复现环境

• 项目：deepseek-ai/deepseek-harness
• DSH 版本：0.1.1-rc.2
• 操作系统：Windows
• 当前 Sandbox 模式：danger-full-access
• 当前 Approval 策略：never
• 受影响的工具：
  • pwsh
  • write
  • edit

复现步骤

1. 启动一个 DeepSeek Harness 会话。

2. 将 Sandbox 模式设置为：

   danger-full-access
   

3. 将 Approval 策略设置为：

   never
   

4. 在当前 workspace 中执行普通的文件编辑或命令，例如：

   Get-Location

   或者修改 workspace 内的文件。

5. 工具调用携带以下任意参数：

   sandbox_permissions: "danger-full-access"
   

   或：

   sandbox_permissions: "workspace-write"
   

6. 调用失败，并出现：

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

   或：

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

期望行为

当当前 Sandbox 模式已经是 danger-full-access 时：

• danger-full-access 不应被识别为权限升级。
• workspace-write 不应被识别为权限升级 downgrade。
• 普通工具调用应直接在当前 danger-full-access 模式下执行。
• 如果当前权限已经足够，调用方应该可以省略 sandbox_permissions。
• Approval 策略不应阻止已经处于 danger-full-access 模式下的普通操作。
• 工具层不应要求调用方再次申请与当前模式相同或更窄的权限。

实际行为

当前工具层似乎将所有带有 sandbox_permissions 的调用都当作权限升级请求，并要求：

requested sandbox mode must be strictly wider than current sandbox mode

因此出现以下错误判断：

current mode:   danger-full-access
requested mode: danger-full-access

被错误地当作无效升级。

同时：

current mode:   danger-full-access
requested mode: workspace-write

也被错误地送入 escalation 分支，而不是被识别为当前权限已足够，或者被明确识别为 downgrade 请求。

可能的根因

问题可能位于 Sandbox 工具调用参数处理、权限模式比较逻辑或 escalation dispatcher，具体可能包括：

1. 没有区分普通调用和权限升级调用。
2. 只要请求中存在 sandbox_permissions，就无条件走 escalation 流程。
3. 没有处理当前模式已经是最高权限模式的情况。
4. 没有定义 danger-full-access 与其他 Sandbox 模式之间的等级关系。
5. 工具 schema 可能要求 sandbox_permissions，但运行时逻辑又要求在当前权限足够时不要传入该字段。
6. danger-full-access 没有被视为无需进一步升级、无需 provider/approval 的特殊模式。

根据 dsh-bash-sandbox 的文档，danger-full-access 是无约束模式，并且不会经过提供方的 Sandbox 限制。因此当前模式下不应再次请求同级或更高权限。

建议的权限判断逻辑

权限处理逻辑可以调整为：

if requestedMode is absent:
    execute using current mode

if requestedMode == currentMode:
    execute normally, not as escalation

if requestedMode is narrower than currentMode:
    execute using current mode, or reject explicitly as an invalid downgrade

if requestedMode is strictly wider than currentMode:
    require approval and perform escalation

也可以抽象为：

requestedMode = undefined

表示使用当前会话模式，而不是触发权限升级。

当：

currentMode === "danger-full-access"

时，应直接执行普通操作，不再进入 escalation 流程。

建议重点检查的代码位置

建议检查以下部分：

• pwsh 工具参数 schema
• write 工具参数 schema
• edit 工具参数 schema
• Sandbox mode 比较逻辑
• escalation dispatcher
• approval policy 与 Sandbox mode 的组合处理
• escalation retry 逻辑
• 当前模式为 danger-full-access 时的特殊处理
• 是否允许在当前权限足够时省略 sandbox_permissions

与普通 Sandbox 拒绝的区别

这个问题不是普通的文件访问拒绝。

普通访问拒绝应类似：

sandbox: file access denied under workspace-write mode

而当前问题发生在权限升级判断阶段：

sandbox escalation ... is not strictly wider ...

也就是说，命令或文件操作本身可能根本没有执行，调用在 Sandbox 参数解析阶段就被拦截了。

Approval 策略的影响

该问题与 Approval 策略有关联，但根因不应归结为 Approval 策略。

在以下状态下都可能出现问题：

sandbox mode: danger-full-access
approval policy: never

此时权限已经是最高模式，工具调用不应该再依赖审批。

当 Approval 策略切换为 ask 后，如果请求的是从 workspace-write 升级到 danger-full-access，审批流程可以正常存在；但当当前模式已经是 danger-full-access 时，再次请求 danger-full-access 不应被视为升级。

影响

该问题会导致：

• 无法修改 workspace 内文件。
• 无法使用 edit 修复代码。
• 无法使用 write 创建文件。
• 无法使用 pwsh 运行构建和测试命令。
• 已授予 danger-full-access 的会话无法继续工作。
• 自动化开发任务会在工具调用层中断。
• 用户需要重启会话或重置运行时配置才能恢复。

期望修复结果

修复后，在以下环境中：

sandbox mode: danger-full-access
approval policy: never

执行：

Get-Location

以及 workspace 内的文件编辑操作时，应当直接执行成功，不再出现：

not strictly wider than this call's current "danger-full-access" mode

同时，从：

workspace-write

升级到：

danger-full-access

的真实权限升级请求仍应保留正常的审批流程。

[173787247]

沙箱 / 权限（「Bug: sandbox escalation error occurs when current mode is already danger-full-access」）

1. 确认当前 session 的 sandbox 模式（workspace-write / danger-full-access 等）
2. 非扩权请求若被实现成抛异常，看起来会像「所有工具都挂」——升级到含修复的版本，或先在受控环境用更宽权限验证是否为该 bug
3. 改权限相关配置后重启并新开会话

把 dsh 精确版本号和触发工具名贴出来，便于对照 changelog。

[argszero]

This is the same root cause as #4976, and both of your error messages come from a single execution check.

Mechanism (source-verified at 0.1.2-alpha.1, cd5ef81481):

1. Whenever a confining backend is composed, the tools advertise the full ESCALATION_TARGETS enum (['workspace-write', 'danger-full-access']) regardless of the session's effective mode — tool-bash/src/index.ts:193 and fs/tool-fs/src/sandbox.ts:45 both build escalationModes = defaultMode === undefined ? [] : ESCALATION_TARGETS.
2. So the model is schema-invited to attach sandbox_permissions even when the current mode is already danger-full-access — a request that is guaranteed to be rejected.
3. approveEscalation (sandbox/src/escalation.ts:157-163) then throws not strictly wider for both equal and narrower requests: WIDER_MODES (escalation.ts:28-31) is read-only → [workspace-write, danger-full-access], workspace-write → [danger-full-access], and nothing is wider than danger-full-access. Your two error messages are exactly these two cases.

Why "narrower also throws" is intentional: the spec test "a non-widening request fails closed with its own text and never asks" (sandbox/tests/escalation.spec.ts:84-90) codifies fail-closed for both read-only → read-only and workspace-write → danger-full-access. The throw is an execution check by design — not a schema constraint.

Design tension worth noting: escalation.ts:34-37 documents why the full enum is advertised — cutting it down to the modes wider than the composition's default would strand a session whose effective mode sits below that default with no lever. So the fix is not "trim the schema at composition time"; it needs per-call resolution — e.g. filter what's advertised against the call's effective mode, or treat an equal-mode request as a no-op (success without approval) instead of a throw. That direction is discussed in #4976.

rc.2 workaround: when the session is already danger-full-access, omit sandbox_permissions entirely (the call then runs under the session's effective mode); the model should stop emitting escalation requests it can never win.

[liyangbing]

这个现象看起来是“请求权限”和“当前有效权限”比较时没有把非扩展请求当作 no-op 处理：danger-full-access → danger-full-access 不应再次进入升级流程，而 danger-full-access → workspace-write 也不可能授予比当前更高的权限。

在修复合入前，可以先让模型/调用方在已经处于 danger-full-access 的会话里省略 sandbox_permissions 字段，不要重复发送 workspace-write 或 danger-full-access；只有确实需要扩大权限时才发送升级请求，并提供非空 justification。这样可以绕开重复升级错误，但不改变任何实际权限边界。

做运行时选型时也建议把“当前会话权限”和“执行后端隔离”分开验证。比如 SandBase Harness 的沙箱表明确区分 local process（不与宿主隔离）以及 Docker/Kubernetes/worker 后端（隔离能力取决于部署），可作为检查权限语义与执行边界的参考：sandbox backends。