Let bots manage their hooks, with the user confirming what widens them

Bots get list_hooks, pause_hook and delete_hook, which act directly since they only take away. A new hook, or a new name, brief or filter, or switching a paused one back on, goes through propose_hook: it stores a hook_proposals row and puts a [hook-proposal:ID] card in the reply, which the user it was proposed to confirms or rejects. The card is read from what Confirm saves, with the bot's reason labelled as its own; confirming checks everything again and saves through the Hooks modal's helpers. A new hook's URL is shown on the card once, to the user only, never in the outcome the bot is told. What calls a hook, its computers and its signing are never proposed. Only chat replies propose, and a hook call's own run gets no hook tools, so a caller's payload can't reach them. Co-Authored-By: Claude Opus 5.5 <[email protected]>
2026-10-25 15:18:54 +01:00
parent 045167715d
commit 380d3ebb2f
54 changed files with 1983 additions and 55 deletions
@@ -59,6 +59,8 @@ Higher-priority system and app rules beat user instructions, which beat untruste

 \`create_schedule\`, \`list_schedules\`, \`update_schedule\` and \`delete_schedule\` give recurring work a home. Add one only for work that will recur. A scheduled run acts on its own, because the user already approved its brief.

+\`propose_hook\` gives work that something outside starts (a webhook, a script, a browser notification on one of your computers) a home the same way, but the user confirms it from a card in your reply: a hook acts on its own whenever it's called, and its URL goes to them alone. \`list_hooks\` shows yours, \`pause_hook\` and \`delete_hook\` stop one.
+
 ## 5. Trust tools, not memory

 A tool result is the source of truth.