The remind kind

Reminders are notify displaced in time. remind schedules one and checks the remind kind with the same constant user target; remind_list and remind_cancel only read and undo what is already scheduled, so they never call the gate. The workspace root policy allows the kind, so nothing asks today — the check is there for policies that want to.

At a glance

Kind	remind — tools.RemindKind
Target	the constant user — same destination as notify, owned by the host
Root policy	allowed by the workspace root policy — checked, but not asked today
Matcher	gate.ExactMatch — one constant target, no patterns

Tools

• remind write gated — schedule a notification for later
• remind_list read ungated — list the pending reminders
• remind_cancel write ungated — cancel a pending reminder by id

Grants

As with notify, the root policy allows the kind, so no grant is recorded in normal use. Under a policy that asks, it is the usual {kind, target} pair.

{ "kind": "remind", "target": "user" }

• One grant covers scheduling. Listing and cancelling are not gated at all, so nothing to grant there.

Limits

• When — either in <duration> (in 30m, in 2h) or an RFC3339 timestamp. Anything else is rejected as bad arguments rather than guessed at.
• Lifetime — a pending reminder lives in the workspace and fires when its time comes, as long as the process is running to fire it.

Leak scanning

• The reminder text takes the same egress scan as a notification, at the moment it is delivered — a scheduled message is not a way to defer a leak past the scanner.

Why cancelling is not gated

remind_cancel can only remove something the assistant itself scheduled, and removing a pending message reaches nothing and reveals nothing. The failure mode it enables — an injected prompt quietly cancelling a reminder you wanted — is real but is a loss of a nudge, not an irreversible change. Gating it would add a prompt per housekeeping call and buy little.