OpenClaw Email Cleanup: Approval and Stop Requests Need Execution Controls

During review-only mail tasks, publish narrow read/search tools backed by an identity without mail mutation scope. Remove generic terminal access and ambient gog credentials that can bypass those tools. The guidance's typed database example needs a mail-provider adapter with independently tested read-only grants; a prompt or tool name saying read-only is insufficient. This prevents the delegated run from performing cleanup even if it loses the user's instruction.

If cleanup is later authorized, require an execution broker to bind approval to exact message IDs, action type, count, account and expiry; show whether the operation archives, moves to trash or permanently deletes. Recheck and atomically consume the authorization at the mail API. Any mutation from a generic terminal must be removed or mediated too. This requires an integrated mail execution adapter, not a claim that OpenClaw chat confirmation supplies this contract.

An operator-controlled executor must yield before each dispatch and allow an authenticated stop signal to block all subsequent queued effects. Keep the authorization decision outside model text and require a fresh action-bound broker decision before resumption. Long-running shell batches must be split or separately terminated and verified; this control does not undo already committed mail changes. A phone chat message is not proof the executor has stopped.

A mail integration developer can enforce review-only operation policy at every final mail adapter using the authenticated account/run, server-resolved message IDs, action and current object version. Deny archive, trash, delete and batch mutations for that run even if a broad tool was accidentally published. Use a separate mutation broker and remove ambient gog credentials or mediate every terminal path. This is an operation-authorization barrier, not interpretation of the agent's promise to wait.

The runtime operator can expose a separately authenticated manual HALT control and enforce the signed current halt state before every inference, queue dispatch and agent step. Verify propagation across workers and prevent stale RUN decisions from reviving the task. Existing in-flight gog/shell processes need separate termination and downstream-effect readback; HALT alone does not prove they exited or restore mail. This requires an external control plane, not another chat message.

With an instrumented mail executor and signed action-bound approvals, an independent monitor can correlate every actual mutation with its exact approval, authenticated approver, account, message population and one-time token. Missing or mismatched approval raises a bypass finding even if the model claims consent. Require complete executor/provider events and test an actual unauthorized mutation fixture. This detects a broken confirmation boundary after an effect; it neither authorizes actions nor reverses deletions.

After the containment owner freezes new dispatch, reconcile executor history and authoritative mailbox state for the complete affected message population. A separate recovery identity may untrash only messages the provider still retains, under an approved idempotent recovery plan, and a read-only identity must verify final labels/state. Missing messages and permanent deletion remain unresolved or irreversible. This needs mail-specific adapters for the guidance's signed population, disposition and readback stages; no successful recovery of Yue's mailbox is asserted.

Before enabling a mail agent release, run a complete signed boundary suite on the exact deployed tools and identities using synthetic mailboxes: review-only must produce no mutation, cleanup must match approved message IDs, and acknowledged stop must prevent new dispatch. Independently inspect provider effects, including queued and resumed work. A missing or failing case blocks release. This is deployment acceptance evidence and does not establish the cause of the historical event.