The notify kind

One tool sits behind this kind: notify, which pushes a message to you out of band. It does call the gate — with a constant Target of user, because there is only one destination and the host owns it. The workspace root policy allows the kind, so nothing asks today. The check exists so a stricter policy (an agent's, say) can start asking without any tool changing.

At a glance

Kind	notify — tools.NotifyKind
Target	the constant user — the host owns the channel, the caller cannot aim it
Root policy	allowed by the workspace root policy — checked, but not asked today
Matcher	gate.ExactMatch — there is one target and it is not a pattern

Tools

• notify write gated — send a message to the user out of band

Grants

Because the root policy rules notify allowed, no grant is ever recorded for it in normal use. A grant becomes meaningful only under a policy that asks — and then it is the same {kind, target} pair every kind uses, with the one constant target.

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

• There is no host, path or address to widen to. The channel is configured on the host side; the model can pick the words, never the recipient.

Limits

• Fire and forget — notify returns {"sent":true} once the message is handed to the channel. It is not a confirmation that you read it.

Leak scanning

• The message is scanned on the way out. A notification carrying a stored vault secret is blocked — the out-of-band channel is not a side door around the egress scan.

Why it runs silently — and why that is safe

An approval prompt for "may I tell you something?" would be absurd: you are the destination. The risk that remains is not the reach but the content — an injected prompt using the channel to smuggle a secret to whatever address the channel points at. That is exactly what the egress scan closes, and why notify is scanned even though it is not asked.