BUG: 会话已是 danger-full-access 时，模型仍反复触发 sandbox escalation to "..." is not strictly wider 错误

[skkjkk]

环境: @deepseek-ai/dsh / dsh-sandbox 0.1.0-rc.6, Windows, Web GUI (dsh web), provider gptcodex (model gpt-5.6-luna)
类型: 工具 schema 广告与模型行为叠加导致的重复报错（无安全问题，调用被 fail-closed 拒绝，未执行任何操作）

现象

会话文件策略为 danger-full-access（最高权限），且会话快照明确告知模型：

Approval prompts are disabled in this session: actions that require approval are rejected automatically — do not request sandbox escalation (do not set sandbox_permissions).

但模型仍然在普通的工作区内写文件调用（write/edit/pwsh，目标都在 workspace 内）上主动附加 sandbox_permissions + justification，每一次都被拒绝：

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

实测统计（4 个 session.jsonl，全部来自同一次任务）：

会话	带 sandbox_permissions 的调用	"not strictly wider" 错误	前置沙箱拒绝
主会话	7（5× danger-full-access + 2× workspace-write）	7	0
子代理 A	4	3（另 1 次是 invalid justification: expected a non-empty sentence）	0
子代理 B	3	3	0

关键事实：

1. 全程 0 次沙箱拒绝 —— 模型是投机性升级，没有任何合法触发条件。
2. 收到错误后模型换枚举值重试（danger-full-access → workspace-write → danger-full-access …），同一个文件反复产生相同错误，浪费大量 token，任务被卡住。
3. 子代理日志里模型的推理原文："写入工具将权限参数误判为升级请求"、"把已有的最高权限错误地当作'待升级权限'" —— 说明模型把 sandbox_permissions 理解成了"声明本次操作需要的权限模式"，而不是"请求升级"。

根因分析

1. 升级字段无条件广告：只要组合挂载了沙箱后端，dsh-tool-fs / dsh-tool-bash / dsh-tool-pwsh 就永远在 schema 里公开 sandbox_permissions（enum 为全局常量 ESCALATION_TARGETS = ["workspace-write", "danger-full-access"]），与当前会话生效模式无关。会话已是 danger-full-access（梯子顶端、不存在更宽模式）时字段依然存在，模型无从得知"升级已无意义"。
2. 字段描述措辞诱导误用："The wider sandbox mode this file operation needs. Only valid as a one-shot retry of an operation the sandbox just denied; requires justification and user approval." 前半句 "the mode this operation needs" 读起来像权限声明，模型（至少 gpt-5.6-luna）会把它当成必填/常规字段在每次调用中附带。
3. 拒绝信息不含可用目标：approveEscalation 的严格更宽检查（WIDER_MODES）在审批之前抛错，错误文本只说明"不是严格更宽"，没有列出当前模式实际可升级到哪些模式；升级提示 escalationHintMarker 也不带当前模式。模型只能盲试 enum 里的另一个值，形成重试循环。

[yun520-1]

"快照明确说了不要"但模型反复请求——这是指令遵守失败，值得拆两层

这个现象（会话快照明确写 "do not request sandbox escalation"，模型却反复在每次 write/edit 上都附加 sandbox_permissions + justification）可以拆成两层看：模型没读到 vs 模型读到了但不理会。

先区分：模型到底看没看到那句指令

帖子说"会话快照明确告知模型"——但模型每轮都重新看上下文，快照内容是否真的进入了模型的上下文、在什么位置、是否被前面的长内容挤出注意力窗口？gptcodex 是外部 provider，它拿到的实际 prompt 是什么，值得先确认。如果快照指令在上下文末尾（或很深的位置），模型注意力没覆盖到，那不是"不听话"而是"没看到"——修法完全不同。

再区分：看到了但不理会（这是更值得修的问题）

如果快照指令确实在上下文里、模型却反复违反，那有几种可能：

1. 指令与行为偏好的权重问题：模型的系统提示/工具 schema 里，"每次工具调用都要带 justification"这类通用指导，和"本会话不要带"这条会话级快照冲突时，模型可能更倾向遵循通用模式（每次调用都带），因为那是它训练里学到的"正确做法"。
2. 错误反馈太温和：每次都被拒（fail-closed），但拒绝信息是 sandbox escalation to "danger-fu..." is not strictly wider——这是技术性报错，没有说"别再加 sandbox_permissions 了"。模型把拒绝理解为"这次的目标权限不对"，下次换个权限再试，而不是"这个会话根本不该请求"。拒绝信息没转译成模型能执行的指令，模型就在原地打转。

建议：拒绝信息要带"行为修正指令"

对 fail-closed 拒绝，除了技术原因（is not strictly wider），应该附一句模型可执行的修正："本会话已是 danger-full-access，后续调用请勿携带 sandbox_permissions 字段"。模型看到后至少有机会改正——现在这个报错只解释"为什么拒绝"，没告诉"下次怎么不触发"。这与 #1093 的 run_code 缺 description 反复被拒是同一类问题：报错说明了失败原因，但没给可执行的修正指令，模型只能盲试。

判别视角（HeartFlow，AGI 第1层辨别者）

"快照说了不要，模型反复做"是一个指令与行为不一致的案例。判别者看这个问题的角度：先别急着怪模型，把"没读到"和"不理会"分开——前者是上下文工程问题，后者才是行为问题。而且无论哪层，报错信息都应该是"行为修正指令"而不只是"失败原因"：fail-closed 保护了安全（没执行任何操作），但没把模型引导回正确行为，拒绝就成了循环。安全护栏的职责不只是拦，还要在拦截时给出下一步可执行的指引——这才闭环。

[lyd123qw2008]

补充一份可审查的本地修复和 Codex 现场证据：36f2d61。

实现方式不是放宽 approveEscalation，而是在 bash / pwsh / fs consumer 取得 standing policy 后，先识别“已被已知 effective mode 覆盖的已知 target”。这种 metadata 是 no-op：不再校验空 justification，也不会产生 approval；任何未知 mode 或真正变宽的 target 仍走原有严格校验、理由与审批。

这正覆盖了 Codex 在 approval never + danger-full-access session 中附带 workspace-write / danger-full-access 的两种失败：not strictly wider 和 invalid justification。更完整的 Windows/Codex 反馈和 PR 拆分建议在 #1215。

[yfzhou0904]

gpt的toolcall一定会输出全部顶级json key，没有办法省略某个key的