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

[zimixvx]

Model GPT-5.6-Sol(Max) (CliProxyAPI)

我明确告诉他Inspect里面的不同(毕竟前面ds toolcall我试了没问题)

[zimixvx]

扫扫

[kitty-eu-org]

+1

[gfushilu07-arch]

我也遇到了

[shanaiardor]

我也是遇到了 不知道为啥

[chenleicode]

我也遇到了此问题，怎么解决？

[OhnkytaBlabdey]

+1

[MrLucy]

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

[MrLucy]

同样的用的是gpt5.6模型

[sedate-cxq]

我也遇到了，让他自己修复了，

[suyiheng544-lang]

也是5.6吗？怎么让他自己修？我说了好几遍了他调用工具还是一直带沙盒权限

[sedate-cxq]

也是5.6吗？怎么让他自己修？我说了好几遍了他调用工具还是一直带沙盒权限

换官网的deepseek修啊

[MrThanlon]

这个问题应该是 openai json schema 解析存在问题导致的, schema 里面 justification 和 sandbox_permissions 是可选, 正常不应该传入, gpt 返回的响应里却包含了这两个属性, 而 ds 自己的模型则不存在这个问题

[MrThanlon]

可以让 dsh 做个插件去替换 sandbox-policy

[ramabondanp]

Same issue

[naipi11]

That message means this call is already running with danger-full-access, so a sandbox escalation is rejected before the command runs. Retry the same command without sandbox_permissions and justification; they do not apply at that mode. If a model keeps adding them, tell it that sandbox_permissions is only valid for a one-shot retry after a sandbox denial from a narrower mode.

[zhang-guo-wen]

+1

[zhang-guo-wen]

让AI自己修复确实有效，改完重启就行了，DeepSeek harness没有提供贡献，不知道啥时候修，自己让AI改一下吧

目前修复已经落盘，核心逻辑、测试和文档都完成了。

在共享 sandbox 包新增 normalizeEscalationArgs()：packages/sandbox/sandbox/src/escalation.ts
pwsh、bash、文件系统 write/edit 均改为先解析实际策略，再处理升级字段：
packages/shell/tool-pwsh/src/index.ts
packages/shell/tool-bash/src/index.ts
packages/fs/tool-fs/src/sandbox.ts
danger-full-access 下会忽略缺失、空白、孤立或同级的升级参数，不校验、不审批，直接执行。
read-only、workspace-write 和无策略组合仍保留严格配对校验、严格拓宽判断、审批及失败关闭。
approveEscalation() 没有修改，同级升级依然不被允许。
验证结果：

共享 sandbox、pwsh、fs 聚焦测试：149/149 通过。
bash 新增的 full-access 回归测试通过；同套测试在 Windows 强行运行时，其余 7 个 POSIX 专用测试按预期失败，因此仓库默认在 Windows 排除该套件。
pnpm run typecheck 通过。
pnpm run lint 通过。
中英文文档配对检查通过。
git diff --check 通过。
Get-Date 实际执行成功，输出时间为 2026年8月20日 17:38:58。

[zhang-guo-wen]

也不好通过插件去修复这个问题，这个所有东西都是插件的说法感觉站不住，还是要依赖官方修复了

外部插件 在现有受支持的插件契约下，不能把它做成一个透明、正确的外部插件。

tool/call 在进入工具策略管线前已经按模型原始参数写入日志，见 packages/core/agent-loop/src/tool-calls.ts:167 和 packages/core/agent-loop/src/tool-calls.ts:263。
ToolRuntime 随后复制并深度冻结执行参数，见 packages/core/tools/src/index.ts:1412。
tools/pre-execute 只能返回 allow、deny 或 ask；契约明确排除了参数重写，因为参数已经记录和展示，见 packages/core/tools/src/index.ts:583。
tools/execute wrapper 只允许临时替换 signal，不能替换 arguments，见 packages/core/tools/src/index.ts:387。
defineTool 的 schema 校验发生在具体工具 body 之前，外部 listener 没有“用清洗后的副本继续调用”的入口，见 packages/core/tools/src/schema.ts:585。
理论上可以写出几种 hack，但都不应接受：

强制 cast 后临时改写 exec.arguments，违反 readonly/日志一致性契约。
shadow 或重新注册 bash、pwsh、write、edit，等于复制四个消费者的 schema、执行、渲染、取消和生命周期逻辑。
在 tools/execute 中递归发起一次清洗后的调用，会重复经过 hooks/guards，制造额外 tools/result，并让实际执行与原始 tool/call 的身份、取消和审计关系不一致。
动态隐藏 schema 字段只能降低模型生成概率，不能修复直接调用、Code Mode 或已生成调用，因而不是执行时保证。
更合理的归属 当前“共享纯函数 + 各消费者在执行边界调用”的结构更合适：

dsh-sandbox 负责升权词汇和通用规范化规则。
bash、pwsh、fs mutation 各自负责解析其调用的 standing policy，并决定这些模型参数是否适用。
sandboxPolicy 服务继续保持 capability-neutral，不需要知道工具名或 sandbox_permissions 这种消费者参数拼写。
如果另做一个 sandbox-escalation-normalizer 服务插件，所有消费者仍必须修改后主动调用它；相比纯函数只增加生命周期和依赖，没有真正实现“外部透明修复”。
若坚持实现为真正透明的插件，必须先修改 dsh-tools，增加一个正式的“保留 raw logged args、另行产生 execution args”的参数归一化扩展点。这会引入两套参数视图，并推翻当前明确禁止 input rewriting 的设计；对这个局部问题明显过重。

[Guducat]

今天也遇到了，GPT5.6出这个问题最严重，不管是Sol Terra还是Luna，希望官方进行修复吧，

我认为当环境处于最高权限danger-full-access的时候，再次申请相同权限被判定为“非法提权”抛出异常属于权限校验逻辑的设计缺陷，

而且多次失败后系统响应也只是被提示

“你正在使用完全相同的参数重复发起一模一样的工具调用。再次调用前请仔细分析上一次的结果：如果任务尚未完成，请尝试更换其他方法或修改参数，而不是一遍又一遍地重试”

把这个信息扔回给模型后也没有提供针对该异常的指导性上下文，导致 Agent 陷入盲目重试，这个真的没办法
我使用的场景是执行远程服务器指令

[nicemkbk]

+1