Approval

Approval

Edge adaptation of the upstream user approval subsystem.

Upstream reference: Approval

What Upstream Provides

The approval subsystem (ctx.approval) gates tool execution behind explicit user consent. It answers "can this specific operation proceed?" with a fail-closed model:

• ApprovalService — distributes approval requests through composed answerers (UI channels for human input, ACP bridge for automation).
• Four outcomes — allowed-once (proceed), rejected (denied), cancelled (withdrawn), unavailable (no answerer). Only allowed-once permits action.
• Session policy — 'ask' (default, delegates to answerers) or 'never' (rejects all, for headless/CI). Policy persists as approval/policy session events.
• Audit trail — approval/asked and approval/decided events in the session log, invisible to the model.

Current Edge Status

Not Implemented The approval subsystem is not installed. No dsh-user-approval dependency, no ctx.approval service, no approval UI in the client bundle.

Practical effect: All tool calls execute without user confirmation. The model can read, write, edit files, run bash commands, and create goals without asking the user first. This is the same behavior as upstream's 'never' policy — but without the option to switch to 'ask'.

Why it's absent: Edge's single-user deployment model (one owner per DO) means every tool call is implicitly authorized by the person who started the session. The approval gate adds friction without security benefit in this context — the user is both the requester and the approver.

Cloudflare Enablers

If approval were needed (e.g., shared deployments, multi-user scenarios):

• WebSocket answerer — the existing mux/host downlink could carry approval request/response frames, using the approval/requested and approval/responded frame types that the client-side connection protocol already defines.
• Plan: Works on all plans. No additional Cloudflare products required — it's a UI interaction layer over the existing WebSocket transport.

Architecture Summary

Component	Status	Notes
ApprovalService	Not installed	All tools execute without confirmation
Approval UI	Not in bundle	Client-side answerer not assembled
Audit events	Not logged	No approval/asked or approval/decided in session log

Key observation: Approval is intentionally absent, not accidentally missing. Edge's single-owner model makes it redundant — the owner implicitly approves all operations by using the system. If shared or multi-user deployments become a goal, this subsystem would be the first to install.

TODO

Evaluate approval for shared deployments. If Edge supports multi-user or shared workspace scenarios, the approval subsystem should be installed. The upstream plugin's inject requirements and the WebSocket answerer transport need evaluation. The client-side approval UI may need to be added to the assembled bundle.