[Bug Report] danger-full-access 下模型重试带 sandbox_permissions 的调用被"not strictly wider"拒绝——升级面不随当前模式裁剪，错误文案被误读为权限系统失效

[DRAG0NM]

摘要

#340 的现象（"开启 full access 前提下，运行期提示 sandbox escalation to "workspace-write" is not strictly wider than this call's current "danger-full-access" mode"）的根因不是权限比较逻辑算错，而是升级表面的三个设计缺口叠加：① dsh-sandbox 的 WIDER_MODES 阶梯表（read-only → workspace-write → danger-full-access）按设计在 danger-full-access 上没有更宽的合法目标，任何带 sandbox_permissions 的重试都会抛这条错误；② 但工具的 sandbox_permissions 字段无论当前模式一律广告（schema enum 是注册表全局的 ESCALATION_TARGETS，代码注释自陈这是为了"默认模式是 full access 但会话被切窄"的场景而保留的全局面）；③ 模型此前在较窄模式下收到过 denial + "retry with sandbox_permissions"提示，用户切到 full access 后模型照提示重试 → 触发降级升级 → 一条读起来像"产品自己判定自己权限不够"的错误。用户因此误判"full access 有时不生效"。

根因（源码定位，rc.6）

1. dsh-sandbox/lib/index.js WIDER_MODES（L29-32）：

   { "read-only": ["workspace-write", "danger-full-access"],
     "workspace-write": ["danger-full-access"] }

   danger-full-access 无键 → approveEscalation（L94）
   !(WIDER_MODES[effectiveMode] ?? []).includes(mode) → 抛"not strictly wider"。
   判定本身正确：从 full access 升级到 workspace-write 是降级。
2. 同文件 L41：ESCALATION_TARGETS 恒为两个目标；工具 schema 的 enum 是注册表全局，
   无法按会话当前模式裁剪（L34-40 注释解释了保留全局面的理由）。
3. 提示链：窄模式 denial → escalationHintMarker（L75-77）教模型
   "retry with sandbox_permissions (the narrowest wider mode that suffices)"。
   会话切到 full access 后，模型照旧重试 → 撞 L94 的拒绝。
4. 错误文案面向开发者而非模型/用户："not strictly wider than ... full access"
   对用户读起来就是"权限系统出了 bug"（权限模式是不是有 bug，full access 有时不生效 #340 的标题即如此解读）。

复现步骤

1. 会话运行于 workspace-write，让模型执行一次会被拒的写入 → 收到
   [sandbox: file access denied ...] + escalation 提示。
2. 把会话权限切到 danger-full-access（此后该写入本可直接成功）。
3. 模型按提示用 sandbox_permissions: "workspace-write" + justification 重试。
4. 结果：报 sandbox escalation to "workspace-write" is not strictly wider than this call's current "danger-full-access" mode（权限模式是不是有 bug，full access 有时不生效 #340 原文）——尽管此时不带该参数
   的同一调用完全能成功。

建议修复

方案 A（推荐）· 降级升级静默放行：approveEscalation 在判定"非严格更宽"时，
先判断 mode 是否等于/窄于 effectiveMode——若是，直接返回 effectiveMode
（视为多余的升级参数，不弹审批、不报错），调用按当前更宽模式正常执行。
语义完全正确：请求者想获得的能力当前已经有了。

方案 B · 按会话模式裁剪提示面：当前模式为 danger-full-access 时，denial
提示不再附带 escalation hint（该模式本无 denial，此路径主要影响 A 之外的
直接升级尝试），并在错误文案中明确"当前已是最宽模式，无需升级"。

方案 C（文案）：把 L94 的错误拆成两条：请求模式窄于当前 → "this call
already runs under the wider mode X; sandbox_permissions is unnecessary"；
请求模式并列/未知 → 保留现有文案。至少消除"产品 bug"的误读。

影响

• full access 用户间歇性撞上"权限系统报错"的假象，模型可能放弃重试或向用户
  报告错误结论
• 每条此类错误都是一次无效的工具往返（token + 时间）
• 安全结论不变：权限边界本身没有漏洞，是升级 UX 面的缺陷（权限模式是不是有 bug，full access 有时不生效 #340 与 [BUG] spamming Error: sandbox escalation to "workspace-write" is not strictly wider than this call's current "danger-full-access" mode #201 同族，
  均属 escalation 表面问题而非边界穿透）

环境

• 源码定位：0.1.0-rc.6（npx 缓存安装包，Node v24.16.0，Windows 11）
• 原报告：权限模式是不是有 bug，full access 有时不生效 #340（0 评论，此前无人分析）

验证材料

• 根因节 4 个源码定位点（含 L94 拒绝判定、L41 全局 enum、L75 提示链）
• 复现步骤 4 步可任意环境执行（第 4 步输出即 权限模式是不是有 bug，full access 有时不生效 #340 原文）

---

First analysis of discussion #340. Happy to open a PR with fix option A.

[MisonL]

补充一组 macOS + Luna 的复现证据，现象与本讨论一致。

环境：

• @deepseek-ai/dsh: 0.1.0-rc.6
• Node.js: v24.19.0
• macOS 15.7.7
• Web mode: dsh web
• Agent model: gpt-5.6-luna（通过本地 OpenAI Responses-compatible provider）
• 会话默认权限：danger-full-access（Web UI 显示 Full access）

复现：

1. 在 Web UI 的新会话中选择 Full access，并让模型调用 Bash 或文件工具。
2. Luna 生成的工具参数仍可能包含 sandbox_permissions（例如 workspace-write），有时 justification 为空或缺失。
3. 工具调用在命令或文件操作执行前失败，错误为：
   • sandbox escalation to "workspace-write" is not strictly wider than this call's current "danger-full-access" mode
   • 或 invalid justification: expected a non-empty sentence
4. 同一会话中去掉 sandbox_permissions 后，pwd、文件读写和删除临时文件均可成功。

额外验证：

• 将 permission.defaultPreset 设为 danger-full-access，新建会话、重启 Web 服务后仍可复现。
• 该错误不表示 Full access 没有生效；它是模型沿用了窄权限会话的升级参数，而工具层在当前已是最宽模式时把它当成非法升级。
• 本机对 dsh-tool-bash 与 dsh-tool-fs 做了最小验证性修复：检测到请求模式等于当前 standing policy 时跳过升级参数校验和审批，工具调用恢复正常。该修改仅为本地热修复，未作为上游补丁提交。

期望：

• 在 danger-full-access 下，工具 schema 或提示不应诱导模型请求更窄的 sandbox_permissions；或
• 将等于或低于当前权限的请求视为冗余参数，按当前 standing policy 执行，并给出明确提示；
• 空 justification 的报错也不应掩盖当前已是 Full access、无需升级的根因。

未包含任何 token、私有路径或会话内容。

[luochenw]

补充一组 macOS + GPT-5.6 Terra 的复现与验证证据，现象与本讨论一致。

环境：

• @deepseek-ai/dsh 0.1.0-rc.6
• macOS
• Web mode
• 模型：GPT-5.6 Terra（通过本地 OpenAI Responses-compatible provider）
• 会话权限：danger-full-access，审批策略：never

复现：

1. 将会话切换到 danger-full-access。

2. 让模型调用 bash 执行一个普通无害命令。

3. 模型仍可能产生如下冗余字段：

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

4. 在未执行命令前，工具返回：

   Error: invalid justification: expected a non-empty sentence
   

   若 justification 非空，则改为：

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

实际捕获到的完整 Bash 参数中，command、description、workdir 都有效；只有这对冗余升级字段阻止了命令执行。

本地验证性修复：

• 在 packages/shell/tool-bash/src/index.ts 中先解析 per-call standing policy。
• 当有效模式已经是 danger-full-access 时，对 sandbox_permissions / justification 做 no-op 处理，再进行普通参数校验和执行。
• 对较窄模式仍保留原有的严格升级校验和审批流程。

验证结果：

• 新增针对 danger-full-access + 空 justification + 冗余 sandbox_permissions 的回归测试。
• packages/shell/tool-bash/tests/tools.spec.ts 通过：87 tests passed。
• 真实模型验证中，Terra 仍发送了上述冗余字段，但 Bash 成功执行并返回预期输出。

这支持方案 A：当请求的目标权限等于或低于当前有效权限时，应将升级字段视为冗余，而不是在命令执行前拒绝调用。未包含 token、私有路径或会话内容。

[t734070824]

遇到同样的问题
在 index.js 中的
if (mode === effectiveMode) return effectiveMode;
解决

[DRAG0NM]

感谢 @MisonL、@luochenw 提供的 macOS + 第三方 provider 跨平台复现证据，以及 @t734070824 的最小修复线索（保持请求模式等于当前有效模式时直接放行）。三组验证共同确认了根因方向：模型沿用窄权限升级参数在最高权限模式下被误判为非法升级。感谢各位补全边界。

[xiaohj233]

I’ve published a small compatibility shim that addresses this failure mode at the model-facing schema layer:

https://github.com/xiaohj233/dsh-compat-shims/tree/main/packages/sandbox-schema-shim

When the current session is already running with danger-full-access, dsh-sandbox-schema-shim removes sandbox_permissions and justification from the model-facing pwsh / bash / edit / write tool schemas.

This prevents the model from generating redundant escalation arguments in Full Access mode, including the cases discussed above:

• sandbox escalation ... is not strictly wider
• invalid justification: expected a non-empty sentence

The shim does not modify the actual sandbox permissions, approval policy, or tool execution path. workspace-write and read-only behavior remain unchanged.

It’s intended as a plugin-based workaround that does not patch upstream files or alter the sandbox/approval execution path, until the issue is fixed upstream.

[DRAG0NM]

Thanks for shipping the shim — removing sandbox_permissions/justification from the model-facing schemas under danger-full-access addresses exactly the redundant-escalation loop we analyzed. Upstream still needs the mode-comparison fix itself, but this is a solid workaround in the meantime.

[2470519590]

我自己弄了个治标不治本思路解决了下，差不多就是在 DSH 的底层沙箱模块加一行兜底判断
找到：

async function approveEscalation(request, approval) {
  const { requestedMode: mode, effectiveMode, justification, subject } = request;

改成：

async function approveEscalation(request, approval) {
  const { requestedMode: mode, effectiveMode, justification, subject } = request;
  if (effectiveMode === "danger-full-access") return effectiveMode;

改完后重启 DSH。GPT 系列模型有时会在工具调用里自动补 sandbox_permissions。
如果当前已经是 danger-full-access，再申请 danger-full-access 就会被 DSH 判定为“不是更高权限”，于是报错。但这个方法只是防止 DSH 报错，不会阻止 GPT 在 payload 里继续写 sandbox_permissions。

[2470519590]

文件位置： ~\dsh\runner\node_modules@deepseek-ai\dsh-sandbox\lib\index.js

[zhang-guo-wen]

有一个插件不知道有没有用，而且这个非常影响使用，我添加litellm的gpt模型，一开启，必现

请帮我安装 DeepSeek Harness (DSH) 插件「dsh-sandbox-escalation-fix」。
仓库：https://github.com/inmny/dsh-sandbox-escalation-fix
简介：DeepSeek Harness 插件：处理DSH沟槽的权限管理（full acess下传入同级或者降级的请求会报错，导致ai大战权限管理）
请执行：

1. 添加插件到 web profile：dsh plugin --profile web add "github:inmny/dsh-sandbox-escalation-fix"
2. 重启 Harness：dsh --profile web
3. 在 Web UI 中确认插件已成功加载。
   如需配置，请查阅仓库 README 中的 cordis.yml 说明。

[imneov]

Follow-up with a tested fix, since external PRs appear to be disabled on this mirror: branch fix/sandbox-escalation-idempotent-non-widening (rebased on current origin/master, commit b552bd4f8c).

Root cause. approveEscalation() in packages/sandbox/sandbox/src/escalation.ts fails the whole tool call when sandbox_permissions requests a mode at or below the call's effective mode. Under a standing danger-full-access session the failure is unrepairable from the model side — no wider mode exists to request — so every escalating call dies before executing anything (models such as the GPT family attach sandbox_permissions defensively, as noted above).

Fix. Make non-widening requests idempotent instead of fatal:

• a requested mode at or below the effective mode reuses the standing mode without consulting the approval channel, and never lowers the call;
• only a strict widening reaches the approval channel, preserving the original guarantee that a non-widening request never prompts a human;
• an unknown mode string is unrankable and still fails closed through the existing WIDER_MODES check with the verbatim not strictly wider text, so the closed vocabulary stays enforced.

This is safer than the if (effectiveMode === "danger-full-access") return effectiveMode workaround above: it handles every non-widening pair (e.g. workspace-write requested under workspace-write), never lowers the call, and keeps unknown modes fail-closed.

Included. Rank-based check ahead of the strict-widening gate; updated escalation specs in dsh-sandbox plus end-to-end reuse coverage in dsh-tool-bash/dsh-tool-pwsh (159 tests passing); a bug-fix Agent Note (en/zh + pairing sidecar); prose updates to the 2026-07-06 sandbox Agent Note and both shell tool READMEs; all doc gates green (verify-agent-note-format, verify-agent-note-classification, verify-md-links, verify-md-wrap, verify-translation-pairing).

Happy to adjust if maintainers prefer a different shape — the branch is a single commit and cherry-picks cleanly onto master.

[KnightForDark]

用它自家模型就没有问题

[ahksl123]

I can reproduce this on Windows PowerShell with:

• DSH: @deepseek-ai/dsh 0.1.1-rc.2
• Session sandbox policy: danger-full-access
• Approval policy: never
• GUI: DSH Web at http://127.0.0.1:3080

Expected:
A write/edit/pwsh call should run with the existing danger-full-access policy
when no escalation is needed.

Actual:
The tool schema requires sandbox_permissions and justification. Supplying either
workspace-write or danger-full-access causes the call to fail before execution:

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

Impact:
The agent can read files but cannot create or edit files, including files outside
the workspace such as a Desktop launcher. The operation succeeds only after
switching the session to workspace-write + ask and approving a real escalation.

Suggested direction:
Do not require or emit sandbox_permissions when the current effective policy is
already danger-full-access. Treat it as an optional escalation-only field.

我在 Windows PowerShell 环境复现了该问题：

• DSH 版本：@deepseek-ai/dsh 0.1.1-rc.2
• 会话文件权限：danger-full-access
• 批准策略：never
• 使用界面：DSH Web，地址为 http://127.0.0.1:3080

预期行为：

当当前会话已经处于 danger-full-access 最高权限时，
写入、编辑或 PowerShell 工具应直接使用当前权限执行，
不应再要求填写 sandbox_permissions。

实际行为：

Web 工具接口要求调用时传入 sandbox_permissions 和 justification。
但无论传入 workspace-write 还是 danger-full-access，
调用都会在执行前失败，报错为：

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

[ahksl123]

使用win11+gpt5.6terra(plus)复现

[memory1moo-cmd]

我甚至用codex开sol去改dsh的配置搞了2个小时，然后才搜到这个页面bug，掉了20根头发。疯了真的是