这合理吗？ 字符串都能完全匹配你跟我说权限不匹配不予执行？？

[Bian-Sh]

提示“Error: sandbox escalation to "danger-full-access" is not strictly wider than this call's current "danger-full-access" mode”
这合理吗？ 字符串都能完全匹配你跟我说权限不匹配不予执行？？

[xydt-tanshanshan]

合理，但这个报错确实容易让人误解。它不是字符串匹配，是权限层级判断。

DSH 的沙箱权限只有三档，升级只允许"严格变宽"（源码 dsh-sandbox）：

const WIDER_MODES = {
  "read-only": ["workspace-write", "danger-full-access"],
  "workspace-write": ["danger-full-access"]
};
// 请求的档位必须在当前档位的"更宽"列表里，否则直接拒绝：
if (!(WIDER_MODES[effectiveMode] ?? []).includes(mode)) throw new Error(...);

danger-full-access 已经是最高档，没有"比它更宽"的权限。你的会话左下角显示 Full access（当前模式 = danger-full-access），而模型在调用参数里又请求升级到 danger-full-access——同档不算更宽，所以被拒。截图里还出现 workspace-write，是模型另一次请求了更窄的档位，同样不在升级表里。而那条命令只是 pwd（查看目录），根本不需任何升级。

建议官方把报错改得更友好。现在的提示只说 "not strictly wider"，用户看到"字符串一样却不执行"会懵。可以改成类似：

当前会话已是 Full access（最高权限），无需升级。模型不应传 sandbox_permissions 参数，直接执行即可。

这样用户一眼就懂，而不是去怀疑是不是权限判断有 bug。

如果要改，位置很明确：

• 报错信息：dsh-sandbox/lib/index.js 的 approveEscalation（约 94 行）——bash/pwsh 共用这一处，改一次全生效。建议在 effectiveMode === mode（同档请求）时附加"当前已是最高/该权限，无需升级"的说明。
• 工具参数说明：dsh-tool-bash / dsh-tool-pwsh 的 schema description（bash 约 289 行）——现在只写 "Only valid as a one-shot retry of a command the sandbox just denied"，可补充"若当前会话已是 Full access 则无需传 sandbox_permissions"。这样模型在生成调用参数前就能看到提示，从源头减少冗余请求。

[Bian-Sh]

是的，就是这个意思，“danger-full-access 已经是最高档，没有"比它更宽"的权限。” 升级只允许"严格变宽" 就走不通，这就是一个明显的bug嘛！

[tancheng33]

两位说的其实各对一半：规则本身合理，但把「同档」和「更窄」判成同一件事，是实打实的缺陷。

看 packages/sandbox/sandbox/src/escalation.ts 的 approveEscalation：

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`)
}

函数上方的注释写明了这是有意的：非加宽请求「throws ... and nothing has run」，整个调用直接失败，而且不会弹给人确认。

问题在于这一个条件同时吃掉了两种语义完全不同的请求：

请求	当前档	语义	现在的行为
workspace-write	danger-full-access	请求更窄 —— 请求本身不自洽	拒绝 ✅
danger-full-access	danger-full-access	空操作 —— 要的就是已有的	拒绝 ❌

第一种 fail-closed 是对的。第二种不是提权：把你已经持有的权限「授予」你，加宽的幅度是零，不存在任何可被利用的越权面。硬失败在这里没有换来任何安全收益，代价却是楼主截图里那个 pwd 整条命令没跑成 —— 一条本来连沙箱都不需要碰的命令。

所以我认为这是 bug，但不是「权限判断写错了」，而是把 no-op 归进了 violation 分支。修法也不必动 WIDER_MODES：

// 同档 = 空操作：什么都没加宽，按当前档继续执行即可
if (mode === effectiveMode) return effectiveMode
if (!(WIDER_MODES[effectiveMode] ?? []).includes(mode as SandboxMode)) {
  throw new Error(/* ... 仍然是更窄/不自洽请求的报错 ... */)
}

这样「严格加宽」对真正的提权路径依然成立（read-only → workspace-write → danger-full-access 一档都没放松），而模型多传一个冗余的 sandbox_permissions 不再让用户的命令陪葬。

@xydt-tanshanshan 提的两处文案改进依然值得做，但我会把它们当作补充而不是替代：靠报错文案和 schema description 去劝模型「已经是最高权限时别传这个参数」，是在用提示词治一个可以在代码里根治的问题 —— 模型偶尔多传一个参数是常态，而一个空操作不该让整条命令失败。