使用cpa反代codex gpt 5.6 luna时 提示权限升级错误

[2DoVe2c]

标题：[Bug] Same-level sandbox_permissions causes invalid escalation error

问题描述：

在 DSH 中，当当前沙箱权限已经是 workspace-write 或 danger-full-access 时，如果工具调用再次传入相同的 sandbox_permissions，工具调用会失败并报告权限升级错误。

该问题可在以下环境中复现：

• DSH portable
• CPA reverse proxy
• gpt-5.6-luna
• Responses protocol

环境信息：

• DSH portable：0.1.1-rc.2
• @deepseek-ai/dsh-web-app：0.1.1-rc.2
• @deepseek-ai/dsh-sandbox：0.1.1-rc.2
• OS：Windows
• Reverse proxy：CPA
• Model：gpt-5.6-luna
• API protocol：Responses
• Approval policy：ask 和 never 下均观察到同类问题

复现步骤：

1. 启动 DSH，并将当前有效沙箱权限设置为 danger-full-access。
2. 调用一个支持沙箱权限的工具，例如 pwsh。
3. 在工具调用中传入与当前权限相同的参数：

{
"sandbox_permissions": "danger-full-access",
"justification": "run the command"
}

以下组合也可以复现：

当前权限：workspace-write
请求权限：workspace-write

实际结果：

工具调用在命令执行前失败，并返回：

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

或者：

sandbox escalation to "workspace-write" is not strictly wider than this call's current "workspace-write" mode

即使当前已经是 danger-full-access，仍然会被当作一次非法权限升级请求。

预期结果：

当请求的 sandbox_permissions 与当前有效权限相同时，应将其视为幂等请求，不应触发审批，也不应报错，而是直接使用当前有效权限执行。

只有在请求权限严格高于当前权限时，才应该进入权限升级和审批流程。

预期的权限关系：

read-only → workspace-write / danger-full-access
workspace-write → danger-full-access
danger-full-access → 无需升级

具体来说：

当前：workspace-write
请求：workspace-write
结果：按当前权限执行，不报错

当前：danger-full-access
请求：danger-full-access
结果：按当前权限执行，不报错

根因分析：

@deepseek-ai/dsh-sandbox 中的 approveEscalation() 只检查请求权限是否存在于严格更高权限列表中。

当前逻辑类似于：

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

当 mode === effectiveMode 时，该请求实际上不需要升级，但当前实现仍然会进入严格权限检查并抛出错误。

对于 danger-full-access，由于它已经是最高权限，WIDER_MODES["danger-full-access"] 没有更高权限，因此同级请求必然失败。

建议修复：

建议在严格权限检查之前增加同级权限短路：

if (mode === effectiveMode) return effectiveMode;

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

这样可以：

• 允许同级权限请求正常执行；
• 不会额外授予任何权限；
• 不会触发不必要的审批；
• 继续拒绝低于当前权限或非法的权限请求；
• 保持真正的权限升级流程不变。

相关代码位置：

源码包：packages/sandbox/sandbox
已安装运行文件：@deepseek-ai/dsh-sandbox/lib/index.js
相关函数：approveEscalation()

关于 Responses protocol 和反代：

当前使用的是 Responses protocol，模型通过 CPA reverse proxy 接入 gpt-5.6-luna。

Responses 风格的结构化工具调用可能会保留或重复传递可选的 sandbox_permissions 字段，但这不应导致 DSH 在同级权限请求上报错。

反代层当然可以避免在普通工具调用中注入 sandbox_permissions，但 DSH 运行时仍应安全处理同级权限请求，因为该请求不会带来任何权限提升。

因此，这个问题的核心应属于 DSH 沙箱升级逻辑的边界处理问题，而不是 Responses protocol 不受支持，也不是用户的权限配置错误。

[Diluka]

gpt-6-astra 也会这样传，它还说是自动补上的参数。gpt-5.5 很正常，不会传多余的。怀疑是不是OAI搞了什么科技在工具调用输出里面。让与codex同名工具参数强制对齐codex，这样其他harness就不能用他们的codex套餐了。

[Diluka]

我在各个系统，不同的harness中，都试过了，基本确定问题出在dsh上面，怀疑dsh和gpt某些模型在schema语义上面有冲突。

1. gpt-6在copilot中正常
2. 在dsh中，如果不是完全访问，那么以上参数可以正常执行
3. gpt-6表示他看见的schema和5.6看见的schema不一样
4. gpt-6尝试像gpt-5.6一样只传两个参数，但是结果还是7个，gpt-6说不是它主动添加的。
5. dsh在Linux和Windows里面一模一样，就算终端工具不相同，最终行为还是一样参数错误。

[Diluka]

已解决，像这样配置：

    - id: gpt-6-astra
      name: GPT-6 Astra
      contextWindow: 1000000
      maxTokens: 128000
      reasoningEfforts:
        low: low
        medium: medium
        high: high
        xhigh: xhigh
        max: max
      compat:
        supportsStrictMode: true

关键是这个配置`supportsStrictMode: true`

[DragonYH]

可以了，非常感谢