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.