[Proposal] Make sandbox escalation session-aware and ignore redundant same-mode requests

[heyallencao]

Problem

In a danger-full-access session, bash, pwsh, write, and edit may still expose sandbox_permissions and justification.

Some models include those fields and repeatedly hit:

invalid justification: expected a non-empty sentence

or:

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

The runtime check is correct: danger-full-access has no wider mode. The mismatch is that tool schemas are registry-global, while sandbox and approval policies are resolved per session.

Proposal

Project escalation options from the effective session policy:

Current policy	Exposed targets
read-only + ask	workspace-write, danger-full-access
workspace-write + ask	danger-full-access
danger-full-access	none
any mode + never	none

When no escalation is possible:

• omit sandbox_permissions and justification;
• remove descriptions or result hints saying escalation is available.

As a compatibility fallback, when:

requestedMode === effectiveMode

ignore the redundant escalation fields and execute under the existing policy without creating an approval request.

Genuine escalation should still require a non-empty justification and approval. Downgrade requests should remain invalid.

ToolRuntime.schemas(scope) and the PTC SDK projection already resolve tools by scope, so a shared scope-aware schema projection point may keep Native and PTC tool calling consistent.

Acceptance criteria

• Sessions with different policies receive different schemas.
• Permission changes affect the next model request.
• Native and PTC expose the same options.
• Same-mode requests do not create approval events.
• Genuine escalation retains the existing strictly-wider and approval checks.
• approval=never does not advertise escalation.

Would a scope-aware schema projection hook in ToolRuntime be the preferred implementation direction?

[argszero]

@heyallencao 你的 #6015 提案质量很高，而且你这套设计(scope-aware schema projection + same-mode fallback)正是这个家族诸多报告里我判断过的收敛方向。先把我复核到的源级事实摆出来，再补两个你可能没注意的点。

源级确认（master 5dda764，0.1.5-alpha.1）

• ToolRuntime.schemas(scope?) 确实存在：packages/core/tools/src/index.ts:1224，接受 ScopeKey，且 :243 注明 schemas() 仅白名单 name/description/…——所以"按 scope 投影 escalation 选项"的落点是现成的。
• 你引用的两条报错正是同一个校验点：packages/sandbox/sandbox/src/escalation.ts：
  • :59 invalid justification: expected a non-empty sentence
  • :163 sandbox escalation to "..." is not strictly wider than this call's current "..." mode
  • :28 WIDER_MODES —— 且 danger-full-access 确实没有键（它是模态顶），所以 any 请求 danger-full-access 到 danger-full-access 必然走 :163 抛错。
• normalizeEscalationMode 目前仍未实现（grep 全仓库为空）——这正是这个家族卡了 9 次报告的根子之一：validation 跑在 normalize 之前，导致"等值声明"先被 :59（空 justification）或 :163（非严格更宽）拒掉，连"这是等值请求"都到不了 policy 层。

你的方案里值得注意的分层

你实际上把修复拆成了两层，这个分法很对：

1. 广告层（schema projection） —— 让不同 policy 的会话拿到不同的 schemas：danger-full-access + never 不暴露 sandbox_permissions/justification；read-only + ask 只暴露 workspace-write/danger-full-access。
2. 裁决层（same-mode fallback） —— 即使模型仍带冗余字段（旧 schema 缓存、模型固执），requestedMode === effectiveMode 时忽略等值声明，直接在现 policy 下执行，不产生审批事件。

这两层缺一不可：只做广告层（schema projection）挡不住"模型从旧 schema / 缓存补丁继续带字段"——这正是很多报告的复现场景（模型看到 schema 说能升级就坚持带）；只做裁决层（same-mode 忽略）又没法让模型提前知道不该带——白走一轮。你两者都提了，方向正确。

两个你需要补齐的点

① same-mode fallback 的触发器位置

你写的是 requestedMode === effectiveMode 忽略并执行。但要注意 validation 现在先抛，所以这个分支必须放在 escalation.ts:59(:59) 和 :163 之前——即在进入 justification / strict-wider 校验前，先判"是否同一模态"。这正是我已经在 #5872 里点过的：

修须在工具层：validation 先于 mode 可知，same-mode 分支须前置。

落点上是：在 validateEscalationArgs / escalation 的入口，先 if (requestedMode === effectiveMode) return（或走"等值请求"短路），再做 justification 非空与 strict-wider 校验。这样才能保证等值请求永不因空 justification 或"非严格更宽"被误拒。

② 你的"Project escalation options"表里有一个隐藏的迁移问题

你把 danger-full-access 映射为"none"。这在新会话下正确，但当前已运行的 danger-full-access 会话，其 client 端 / 已生成 schema 仍带 sandbox_permissions 字段。切到"none"后，模型那侧是否仍是旧 schema？如果只改服务端 schema projection 而不处理已缓存/已下发的 schema，模型会继续拿着旧 schema 发等值请求——正好被你的 same-mode fallback 接住。所以这两层互为保险，你设计里"可能保持 Native 与 PTC 一致"这个顾虑也是对的，但建议把"旧 schema 下发兼容"写进验收标准（如"升级后已存在的 danger-full-access 会话，模型继续发等值请求不产生审批"）。

一句话结论

方向对，落点建议:广告层做 schema projection（按 policy 投影可升级目标），裁决层前置 same-mode 分支（在 justification/strict-wider 校验之前短路等值声明），并补一条 normalize-escalation 的谓词归一避免"近似更宽"误判。这个家族我第一次见的时候（#5611/#5847/#5872）就已经收敛到这三件套，你现在的提案基本是同一方向——建议直接按"广告层 + 前置 same-mode"的形态提。

（附带：danger-full-access 本身没有更宽模态，所以表里"none"是对的；但 approval=never 下即使当前是 read-only 也不应暴露升级——你的表已含这一行。整体一致性我确认。）

[heyallencao]

感谢你的源码级复核，这两个补充很有价值。

我同意 same-mode 判断必须发生在 justification 和 strictly-wider 校验之前。实现上有一个细节：当前 validateEscalationArgs() 只接收 sandbox_permissions 和 justification，拿不到 effectiveMode，因此不能直接判断是否同级。

是否先解析 standing policy，再通过一个 Bash、Pwsh、Write、Edit 共用的 helper 处理 escalation request会更好呢：

resolve standing policy
→ exact same-mode: 移除冗余字段并按当前 policy 执行
→ genuine escalation: 校验 justification，再进入 approveEscalation()
→ downgrade / invalid target: 保持非法