[bug]工具沙箱升级引导在 danger-full-access + 审批 never 会话中造成无限失败循环

[wizzy-yang]

问题
在采用 danger-full-access 预设（沙箱模式 danger-full-access + 审批策略 never）的会话中，代理（agent）无法完成任何工作区之外的文件修改——所有携带 sandbox_permissions/justification 的工具调用都会被拒绝，模型陷入死循环，不断换不同的升级值重试，完全无法推进。已通过自定义 openai-responses 网关上的 GPT-5.4 复现；该行为与模型无关。

"升级毫无意义"这一信息确实被注入了（sandbox-policy 运行时上下文："DSH 文件沙箱不限制文件修改"；user-approval："不要请求沙箱升级（不要设置 sandbox_permissions）"），但工具链的其它部分在极力压过它：

工具描述把"升级"宣传成"唯一正确的恢复路径"。 dsh-tool-pwsh / dsh-tool-bash 花大篇幅描述"当命令被拒绝时……立即升级……用 sandbox_permissions + justification 重试"；而"审批禁用 → 不要设置 sandbox_permissions"这条例外只是结尾处的一个从句。
拒绝信息具有误导性。 sandbox escalation to "workspace-write" is not strictly wider than this call's current "danger-full-access" mode 读起来像是在说"请选一个更宽的值"——但根本不存在更宽的值。它从未说明"本会话禁止升级"。
没有动态适配。 即使 sandbox_permissions 永远不可能成功，它仍然被完整地展示在工具说明中。
复现步骤
会话配置为 permission.defaultPreset: danger-full-access（沙箱 danger-full-access，审批 never）。
让代理编辑一个工作区之外的文件（例如 node_modules/... 下的包）。
模型调用 edit/write/pwsh 并携带 sandbox_permissions →
Error: sandbox escalation to "workspace-write" is not strictly wider than this call's current "danger-full-access" mode
（当 justification 为空时）Error: invalid justification: expected a non-empty sentence
换 danger-full-access、其它模式、其它 justification 重试 → 得到完全相同的拒绝。无限循环。
预期行为
当审批策略为 never（或沙箱模式已是最高级）时，升级不可能成功，因此也不应该被提供：

工具应省略 sandbox_permissions 参数以及所有升级引导，或者
拒绝信息应直说："本会话禁用升级；请在不带 sandbox_permissions 的情况下重试该调用。"
建议修复
工具描述/schema 动态渲染：当会话的有效审批策略为 never（或模式已是最高级）时，从 dsh-tool-pwsh、dsh-tool-bash 以及 edit/write 工具中剔除 sandbox_permissions 和升级相关段落。不可能成功的能力就不应该被宣传。
拒绝信息：为"升级已禁用"的情况增加分支（"本会话禁止沙箱升级；请不带 sandbox_permissions 重试"），而不是"不低于当前模式"。
把 never 策略放进稳定的系统提示（system prompt）而不是只放在运行时上下文快照中（目前通过 approval:policy 以 order 115 注入）。
参考资料（dsh v0.1.0-rc.6，web profile，Windows，Node 24）
dsh-sandbox-policy/lib/index.js 第 83–94 行（renderPolicyContext，面向模型展示的模式文本）
dsh-user-approval/lib/index.js 第 38 行（NEVER_SENTENCE）、第 92–102 行（systemPrompt 注入）
dsh-tool-pwsh/lib/index.js 第 144 行、dsh-tool-bash/lib/index.js 第 129 行（升级引导文本）

[xiaozihanpk]

同样的问题

[JUSTMONIKA2022]

同样的问题，sol直接接不了

[galaxywithu]

一样

[DuanYihui]

本地按以下方式修了一轮，能跑了

————————————————

现象

配置 OpenAI 类模型（如 gpt-5.6-sol，走 openai-responses 代理）后，会话里持续刷红：

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

模型反复重试、反复报错，几乎每次 bash 调用都被拒，进入死循环。

复现条件

1. 使用 OpenAI/Codex 类模型；
2. 会话有效沙箱权限切换到 workspace-write 或 danger-full-access；
3. 模型在工具调用里预防性地带上 sandbox_permissions + justification，而不是只在看到 [sandbox: file access denied ...] 拒绝标记后才作为一次性重试。

根因

沙箱提权只允许「向更宽的一档跳」：

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

approveEscalation()（packages/sandbox/sandbox/src/escalation.ts）执行的是严格 widening 校验：

• 模型填了当前权限本身（例如已处于 danger-full-access 又填 danger-full-access，或已处于 workspace-write 又填 workspace-write）→ 判定「不是更宽」，抛 not strictly wider；
• 填更低/未知权限 → 同样拒绝。

而某些模型不遵守「看到拒绝标记才提权」的约定，会预防性填字段。于是「同档请求被拒 → 模型看到报错 → 换值重试 → 再被拒」形成死循环。本质是 fail-closed 设计对不守约定模型的鲁棒性缺口——danger-full-access 已是天花板，此时任何 sandbox_permissions 取值都不再合法，模型每加一次就红一次。

修复思路

1. same-mode 幂等放行：当 requestedMode === effectiveMode 时，直接按当前有效模式执行、不弹审批（不授予任何更宽权限，安全）。更低的、未知的仍然拒绝。

2. 按会话有效权限收窄 schema 枚举（把「从某模式还能往哪升」抽成 widerModesFor()）：

   • read-only → 暴露 ['workspace-write', 'danger-full-access']
   • workspace-write → 只暴露 ['danger-full-access']
   • danger-full-access → 不再暴露 sandbox_permissions

   即：schema 不再永远展示完整的 ['workspace-write', 'danger-full-access']，而是按会话当前有效模式动态收窄，从源头避免把「永远不可能成功」的参数摆给模型。

3. 统一收口：bash、pwsh、write、edit 四个工具，以及 Native 与 Code Mode（SDK）两条 schema 投影路径，共用同一套收窄逻辑（给 ToolDefinition 增加一个按 agent/session 解析参数的钩子，投影时传下去）。

验证（本地）

按上述思路在本地实现后：

• host / client 两侧 tsc -b 类型检查均通过；
• 相关 4 个测试文件（sandbox escalation + bash/pwsh/fs tools）共 234 个用例全部通过。

[JUSTMONIKA2022]

我写了一个插件，解决了沙盒升级的问题，没有动dsh的核心代码，可以来用用看

[naipi11]

同样卡在这条报错上的人 +1。这个其实是工具描述在"教"模型去做一件永远不可能成功的事，楼上的根因分析已经很到位。补充几个不用改源码、也不用插件的绕法：

1. 会话里直接跟模型说一句：任何工具调用都不要带 sandbox_permissions / justification，danger-full-access 下沙箱本来就不限制文件修改，命令被拒就原样重试一次。OpenAI 系模型一般会被这条用户指令直接拉回来，循环当场打断。
2. 想以后都生效：把同一句话写进项目根目录的 AGENTS.md（或者 ~/.dsh/AGENTS.md，对所有项目生效）。dsh 会把 AGENTS.md 注入会话上下文，新建会话后自动带上。
3. 如果你们也是走自定义 openai-responses 网关：在网关侧把工具调用参数里的 sandbox_permissions、justification 直接剥掉再转发。danger-full-access 下这两个字段没有任何成功路径，剥掉不会损失任何权限，还能从根上杜绝循环。

刚拉了 master 最新（rc.7），packages/sandbox/sandbox/src/escalation.ts 里的 WIDER_MODES、ESCALATION_TARGETS 和那条 "not strictly wider" 报错还是原样，bash / pwsh / edit / write 的工具 schema 也仍然固定展示这两个升级参数。所以这不是模型抽风，上游确实还没修。

给维护者的建议（与楼上思路一致）：schema 按会话当前有效模式动态收窄：danger-full-access 时直接不展示 sandbox_permissions；拒绝文案也改成"本会话禁用升级"，而不是"不低于当前模式"。这两处改完，这类死循环基本就不会再出现。

English summary: the tool schemas still advertise sandbox escalation in danger-full-access sessions where no wider mode exists; quick no-code workarounds are to instruct the model not to send sandbox_permissions, or strip those two params at a custom gateway. Master (rc.7) is still unfixed.

[AlexBybye]

已确认按照这位大哥1-2可以解决沙箱问题 😃