E.D.I.T.H. owner approvals

Review and decide

Open #/agents/edith/approvals in the private HUD. Each request includes its ID, tool, creation time, producer origin, purpose, effect and exact arguments. New worker requests preserve the actual originating task text. Older records explicitly identify missing task details instead of inventing a rationale. A message's recipient and full body belong in the review.

Accept executes the queued tool now. Reject records a decline without invoking the handler. Only pending requests are actionable. The service records execution and resolution separately.

Protection against mistakes

A revision binds consent to the ID, tool, arguments, origin and creation time. Changed or resolved requests return a conflict. Execution is durably claimed before yielding, preventing duplicate clicks and competing voice approvals from replaying it.

Acceptance is disabled when display sanitization hides or shortens action details. Unclassified actions remain subject to policy escalation. A click cannot bypass a policy denial or handler interlock. An executing record after a crash has an uncertain outcome and must not be automatically replayed.

A separate authenticated endpoint

Owner consent does not travel on the display token. The gateway serves the approval route under its own check: remote access is authenticated by the tailnet, local development requires the broker credential and an exact loopback origin, and a write requires the explicit approval header.

That separation is the point. A token that can read the display can observe the owner's operational state; it cannot act on it.

Deployment requirement

The brain, gateway and frontend must all support the consent API. A frontend update alone cannot activate it on an older remote deployment. Display tokens cannot approve; the gateway requires the configured private owner identity or authenticated loopback development broker.