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 之前，保留原始调用并将审批与其绑定，整体会更清晰。

[Astro-Han]

Thanks everyone. We have consensus on moving sandbox approval into Runtime pre-dispatch. I propose closing this Discussion with the following convergence:

• one revisioned, Session-scoped SandboxPolicy: auto | full_access | external;
• Runtime evaluates ordinary tool calls before first dispatch and keeps the original call pending when approval is required;
• approval and policy changes are Runtime-owned, not model-driven;
• remove request_sandbox_boundary, boundary_intent, required_boundary, and negotiation counters;
• Bash runs under the current policy without per-command escalation;
• platform toolchain dependencies belong to a fixed, read/execute-only backend substrate.

The observed sandbox failures remain tracked in #4267 and its forthcoming scoped sub-issues. #3731 should be revisited against this decision rather than adding a separate negotiation-state authority.

I’m closing this Discussion as the architecture direction is settled. Implementation and verification will continue through Issues and PRs.

中文

大家已经对 Runtime pre-dispatch 的方向达成共识，最终收敛为：

• 使用唯一、Session 级、带 revision 的 SandboxPolicy；
• Runtime 在工具首次执行前完成判断和审批；
• 删除模型侧提权工具、声明参数和 negotiation counters；
• Bash 不支持逐命令提权；
• 系统工具链依赖由 backend 提供固定的只读/执行 substrate。

实际 sandbox 故障继续由 #4267 及后续子 Issue 跟踪。#3731 也应根据这个决策重新评估，不再增加独立的 negotiation-state authority。

架构方向已经确定，因此关闭本 Discussion；后续施工和验收通过 Issue 与 PR 推进。

AI assistance disclosure: OpenAI Codex, Claude, and K3-256K assisted with the architecture and naming analysis. I reviewed this conclusion and take responsibility for it.