It doesn’t match the model’s text. The check runs in the accessibility service on the actual button the tap would land on: its label, icon description and view id, as the app reports them. The model can write D E L E T E all it wants, the button still says Delete. It also can’t tap Buddy’s own approval card to approve itself.

Where it can miss: a button with an odd or blank label, and apps you mark as trusted, where asking is left to the agent. And agreed, it’s one guard, not the whole risk picture. Prompt injection from what’s on screen is the bigger open problem, and the approval card is the backstop there.

Curious too. In my tests Qwen3 4B and 8B handled one-step requests but fumbled multi-step ones (tapped the wrong buttons, then said it worked). gpt-oss 20B did better but was inconsistent: one run got a 2-step task right, the next claimed a tool didn’t exist. I haven’t tried a 27B yet, and I don’t know if it’ll even run usably on my RTX 2060 Super (8 GB). If anyone runs one through Ollama or llama.cpp, I’d love to hear how it does.

Fair to be skeptical, but it isn’t the model being asked nicely. Buddy checks every tap itself: when the button is Send, Post, Buy, Pay, Delete and similar (by its label or id, in several languages), Buddy stops and shows an approval card, whatever the model wants. It’s a word list, so an oddly named button can slip through; it’s all in Guard.java if you want to look: https://github.com/ghorbelhamdi/buddy-android/blob/main/app/src/main/java/app/buddy/assistant/Guard.java