Why sending is a switch, not a setting

Every demo of an assistant with messaging access ends the same way: it sends something. Usually to the right person. The interesting question is what happens on the day it does not.

Reading a chat is recoverable. Someone saw something they did not need to see, which is bad, and it stops there. Sending is not recoverable. The message is on someone else's phone, with your name on it, in a relationship you have to keep afterwards.

Confirmation dialogs are weaker than they look

The usual answer is a confirmation step: show the user the message, let them approve. Good clients do this, and you should prefer one that does. But it is a property of the client, not of the server — and clients vary, run in batch mode, and get configured to auto-approve by users who got tired of clicking.

So the guarantee cannot live there. It has to live where the tool list is built.

Not registered beats disabled

For an account without write access, send_message is not in the tool list at all. The model never sees it, never plans around it, never tries. There is no code path where a flag is checked late and read wrong, because there is no flag: the tool was simply never added to that server instance.

Underneath, reads go one step further and run the CLI with its own read-only guard, which refuses anything that would write to WhatsApp or mutate the store. Two independent mechanisms, one intent.

The default changed, and this note changed with it

This post used to be called Why sending is off by default, and it described a flow where you linked an account read-only and asked for write access afterwards. On 18 September 2026 that default flipped: the checkbox on the linking page now starts ticked, and unchecking it links the account read-only.

The honest reason is that the old default was not protecting anyone. It produced accounts that could not do the one thing their owner had linked them for, followed by a request to turn it on — a request nobody evaluates carefully on the second attempt. A decision you make while looking at a checkbox, before scanning a code, is a real decision. A decision you make because something is broken is not.

What did not change is the part that carries the guarantee: write access is fixed when you link, it is per account, and declining it leaves you with the thirteen read tools and no write tools in the list at all. The switch is the same switch. Only its starting position moved, to the place where you can actually see it.

A default is a guess about what you want. A switch you tick before scanning is an answer.

What sits behind the switch

More than sending. check_numbers_on_whatsapp only reads, but it reads by asking WhatsApp about a stranger's number, which is a small act of reconnaissance and a plausible enumeration tool. Marking a chat read sends a read receipt, so quietly telling someone you have seen their message is a side effect on their screen, not yours. Reactions are visible to everyone in the chat.

If a tool changes what someone else sees, it belongs behind the write switch — even when it technically only reads.

What stays off entirely

Bulk sending is not a feature that will appear later. It is what gets numbers banned, it is what makes this category of tool a nuisance, and it is on the not-planned list for both reasons. The write switch exists for conversations, not campaigns.

If you are evaluating this on an account you care about: link it with the box unchecked, live with thirteen read tools for a week, and ask for write access afterwards — the flag flips on your account, no relinking and no new token. That is still the advice, and it is still the thing we would do.