Skip to main content

Tap to approve

When the box wants the owner's sign-off, it sends a link. The owner taps it, sees exactly what will happen, and taps Approve or Decline. Only then does the box run the one command it wrote down in advance.

Where you see it​

A message arrives with a link. Tap it and a page opens. It shows what the action is, for example an email and who it goes to. Below that are two buttons: Approve and Decline. There is no password to type.

What happens, step by step​

Say an agent drafted a reply to a new customer, and the send guard put it on HOLD because the agent isn't allowed that person yet.

  1. The agent calls approvals.create. This writes a small file holding the exact command to run, plus a preview page. It also writes down the full location of every program and file the command needs, so nothing is looked up later by a bare name. The box then tests the command the same way a yes will run it, without sending anything. A send that could not work is refused right there, so the owner is never asked to approve it.
  2. The box sends the owner a link, by email, WhatsApp, or the chat page.
  3. The link carries a token (a long random code, 32 bytes). The token is the only key. It works once.
  4. The owner taps the link and sees the preview.
  5. On Approve, the box runs the exact command it already recorded. It runs it as a list of separate words, never as a shell string (one line of text the computer re-reads and could be tricked by). The tap supplies no text at all, only the choice: yes or no.
  6. On Decline, nothing runs.
  7. When a send finishes, the box closes out the request, the question behind it, and any "yes" note waiting in the agent's inbox. If a failed send goes out later, by another try or by hand, that old yes is closed the same way, so the same message is not sent twice.

Because the command is fixed before the link is sent, a stolen link can only approve that one thing. It can't be edited into something else.

What powers it​

PartWhat it does
approvals.pyRecords the command, makes the token and the preview, runs the command on yes.
auth_door.pyThe small web server behind the link and its Approve and Decline buttons.
The pending-approval fileHolds the one exact command, written before the link goes out.
send-selftest.pyOnce a day, runs a check-only test approval through both paths. Nothing is sent.
One shared runnerThe chat page and the phone link both run a yes through the same code and setup.

Why it works this way​

Why a tap, not a reply. No inbox has to be read. No reply has to be parsed. Nothing depends on how a mail app shows a picture. The same pattern already works for reconnecting Google logins.

Why a list, not a string. If the box built the command from text at tap time, a crafted request could slip in extra words. Recording the command as a fixed list first means the web request can't change a single word of it.

No expiry. A link stays good until it is answered once. The owner may be busy for a day. The action waits.

Treat the link like a password

Whoever has the link can approve that one action. That's why it only goes to the owner's own inbox or phone. Don't forward it.

A yes always sends. The chat page and the phone link run a yes the same way, with the same setup, and that is also the setup the ask-time test uses. That way a test that passes when the agent asks means the same thing when the owner taps. A new agent needs nothing set up for this. If a yes is tapped and the send still fails, the card says in one plain line what did not go out and why, and nothing went out.

The daily self-test runs a check-only approval through both approval paths, the chat door and the phone link. It proves each path can run the send guard, without sending any message. If either breaks, Otto gets it and the owner gets one WhatsApp line naming which path. A gate that is quietly broken looks the same as one that works, until the day it matters.

Connected to​