Move sandbox approval into Runtime pre-dispatch

[Astro-Han]

Problem

Sandbox approval is currently initiated by the model through request_sandbox_boundary.

This creates an unnecessary loop:

tool fails
→ model requests permission
→ user decides
→ model retries the tool

Runtime already knows the active ExecutionBoundary, the original tool call, and often the exact missing capability. The model should choose the operation, not control the permission state machine.

The current design also exposes request_sandbox_boundary in full-access sessions. A request can reach the user even when the boundary is already bypass, then settle as boundary_kind_changed.

Proposed behavior

Permission checking should happen before tool dispatch:

tool call
→ Runtime capability preflight
   ├─ allowed: dispatch
   ├─ needs approval: wait for user
   │  ├─ allow: revalidate, then dispatch for the first time
   │  └─ deny: return a typed denial to the model
   └─ unsupported: return a typed capability error

Permission waiting is not a tool failure, and allowing access is not a retry.

Each invocation should produce one model-visible tool call and one final result. This likely requires separating durable tool intent from actual dispatch:

T0: tool intent committed
P:  optional permission wait
T1: tool dispatch committed
T2: final outcome committed

The model-visible request_sandbox_boundary tool can then be removed. Existing Host interaction, settlement, recovery, and UI prompt machinery should remain.

Bash may still need required_boundary, since Runtime cannot safely infer the resources used by an arbitrary command. That field should describe the original operation's requirements. Runtime should handle approval.

Windows

Windows currently uses the packaged AppContainer broker for the purpose-built filesystem worker. Managed arbitrary shell execution is not supported and fails closed. Some file mutations also cannot be represented precisely by the current ACL policy.

The preflight contract must therefore distinguish:

• access the user may approve;
• access already covered by bypass;
• capabilities the platform cannot enforce.

User approval must not turn an unsupported Windows operation into unsandboxed execution. Windows sandbox work remains tracked in #2142.

Questions

1. Should the durable tool protocol split intent from dispatch?
2. Which executors should provide capability preflight?
3. Should approved access remain Session-scoped?
4. How should public tool and embedding APIs change?
5. What should managed Bash do on Windows until shell sandboxing exists?

AI assistance disclosure: Drafted with Maka and subject to human review.

[Astro-Han]

@YayoiNanoka @liugddx, this proposal touches the permission-escalation model and the Windows AppContainer sandbox. I’d appreciate your views, especially on keeping the original tool invocation pending before dispatch and distinguishing user-approvable access from capabilities Windows cannot enforce.

Automated message from Maka, posted at the discussion author’s request.

[liugddx]

Thanks for looping me in. I agree with this direction.

A missing sandbox capability should not surface as an ordinary tool failure followed by a model retry. Runtime should preflight the original invocation, keep it pending, and ask the user only when the missing access is something the user can approve.

The intended behavior would be:

• allowed: dispatch the original invocation;
• approval_required: keep that invocation pending, ask the user, revalidate the current boundary after approval, then dispatch it for the first time;
• denied: return a typed denial to the model;
• unsupported: return a typed capability error.

If the current boundary is already bypass, Runtime should dispatch directly and never create an approval request. For Windows/AppContainer capabilities that cannot be enforced, user approval must not become an implicit escape hatch to unsandboxed execution; those should remain explicitly unsupported and fail closed. This is consistent with the support boundary tracked in #2142.

For the first implementation, I would keep the intent/dispatch bookkeeping internal to Runtime so each invocation still appears to the model as one tool call with one final result. I also agree that Bash may need to retain required_boundary, because Runtime cannot safely infer the resources used by an arbitrary shell command; Runtime should own the approval state machine around that declaration.

[YayoiNanoka]

Thanks for the proposal. LGTM.

For context, I designed the earlier auto-approval review in #1016, inspired by Codex's Guardian-style flow. The intention was for a separate LLM query—not the acting model—to review the original user intent together with the exact requested action, justification, and risk, and then allow or deny the request fail-closed.

I may have missed the context behind the later refactor in #1581, but the flow eventually became model-driven: after a tool reports a concrete missing capability, the acting model calls request_sandbox_boundary to initiate the boundary expansion request.

I agree with the proposal here. Moving capability checks and approval handling into Runtime pre-dispatch, while keeping the original invocation pending and binding the approval to it, is a cleaner design.

中文

感谢这个提案，整体 LGTM。

补充一点背景：#1016 中较早的自动权限审核是我设计的，思路参考了 Codex 的 Guardian。原本希望由一个独立的 LLM 请求——而不是正在执行任务的模型——结合用户的原始意图、具体操作、提权理由和风险，决定允许或拒绝，并在审核失败时默认拒绝。

我可能遗漏了 #1581 后续重构的一些背景，但最终流程变成了由执行任务的模型在工具报告具体能力缺失后，调用 request_sandbox_boundary 发起边界扩张申请。

我赞同这里提出的方案：把能力检查和审批状态机移到 Runtime 的 dispatch 之前，保留原始调用并将审批与其绑定，整体会更清晰。