danger-full-access 权限下 bash/edit/write 工具无法执行的问题

[ecinsight]

Harness 当前存在权限校验问题：在会话已经处于 danger-full-access、且 Approval prompts 为 Disabled 的情况下，调用 bash、edit 或 write 工具仍会重复触发 sandbox escalation。传入 danger-full-access 会报 sandbox escalation to "danger-full-access" is not strictly wider than this call's current "danger-full-access" mode，传入 workspace-write 也会报 sandbox escalation to "workspace-write" is not strictly wider than this call's current "danger-full-access" mode。因此读取文件正常，但无法修改或创建文件，也无法运行 lint、测试和构建。预期是在当前权限已经满足请求时直接执行工具，或跳过重复的权限升级校验。初步判断是 Harness Runtime 的会话权限状态与 bash/edit/write 工具的 sandbox 权限校验逻辑不一致。

[shanliuling]

看了一下当前 master 的 sandbox / bash 实现，这个报错的原因应该不是 danger-full-access 本身没有生效，而是 tool call 在已经处于 danger-full-access 的情况下仍然携带了 sandbox_permissions。

packages/sandbox/sandbox/src/escalation.ts 里的权限关系目前是：

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

也就是说 danger-full-access 已经是最高权限，没有任何可以继续 escalation 的目标。

而 bash / edit / write 只要参数里出现了：

{
  "sandbox_permissions": "danger-full-access",
  "justification": "..."
}

就会在真正执行操作之前进入 approveEscalation()。

因此当前权限已经是 danger-full-access 时，就会直接命中：

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

传 workspace-write 同理，因为它反而比当前权限更窄，也不属于 escalation。

所以这里可以先试一下：调用 bash / edit / write 时完全不要传 sandbox_permissions 和 justification。

例如已经是 danger-full-access 时，bash 应该直接：

{
  "command": "pnpm lint",
  "description": "Run project lint"
}

而不是再附带 sandbox_permissions。

另外当前 tool-bash 的 prompt 里其实也明确写了：如果 session 显示 Approval prompts are disabled，不要设置 sandbox_permissions。因此如果是 Agent 在每次调用 bash/edit/write 时自动补上这两个字段，我感觉更像是 模型/tool-call 层没有正确遵循当前 sandbox policy context，而不是底层 sandbox 实际拒绝了写入。

建议看一下失败调用的 raw tool arguments：

• 如果里面确实一直有 sandbox_permissions，那基本可以确认是这个问题；
• 如果已经完全没有 sandbox_permissions，在 danger-full-access 下仍然无法执行 bash/write/edit，那才更像是 sandbox policy / executor 的实际 bug。

如果方便的话可以贴一个失败的 bash 或 write 的完整 tool call 参数，这样应该能进一步确定是哪一层出了问题。

[ecinsight]

我让我的ai读了一下已经确认是这个问题了，我让他修一下

[shanliuling]

好的,有帮助可以点个正确答案哦

[shuzixin]

修复方案：

---

修复 Bash/Edit/Write 在完全权限下无法执行

问题

当会话已经是 danger-full-access 时，工具调用如果仍携带：

{
  "sandbox_permissions": "danger-full-access",
  "justification": "..."
}

会被错误当成一次新的权限升级，并报错：

sandbox escalation to "danger-full-access" is not strictly wider

修复方法

修改：

packages/sandbox/sandbox/src/escalation.ts

在 approveEscalation() 中，严格权限升级检查之前加入：

if (mode === effectiveMode || (WIDER_MODES[mode] ?? []).includes(effectiveMode)) {
  return effectiveMode
}

完整位置如下：

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

  if (mode === effectiveMode || (WIDER_MODES[mode] ?? []).includes(effectiveMode)) {
    return effectiveMode
  }

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

  // 原有审批逻辑保持不变
}

修复后的行为

当前权限	请求权限	行为
danger-full-access	danger-full-access	直接执行
danger-full-access	workspace-write	直接执行
workspace-write	danger-full-access	正常请求审批
read-only	workspace-write	正常请求审批
未知权限	任意权限	继续拒绝

建议同步修改提示

在 Bash、PowerShell 和文件工具的 schema 描述中加入：

普通调用不要携带 sandbox_permissions 或 justification。
只有同一个操作刚刚返回 sandbox escalation marker 后，才能使用最小的更高权限重试。

涉及文件：

packages/shell/tool-bash/src/index.ts
packages/shell/tool-pwsh/src/index.ts
packages/fs/tool-fs/src/sandbox.ts

验证

运行：

pnpm exec vitest run \
  packages/sandbox/sandbox/tests/escalation.spec.ts \
  packages/shell/tool-bash/tests/tools.spec.ts \
  packages/shell/tool-pwsh/tests/tools.spec.ts \
  packages/fs/tool-fs/tests/tools.spec.ts

预期结果：

Test Files  4 passed
Tests       232 passed

修改后需要重启正在运行的 Harness Web/Host 服务，使新的 bundle 生效。

---

[ecinsight]

我让我的ai读了一下已经确认是这个问题了

[shuzixin]

是的，我按这个方案已经修复好了