Self-hosted WhatsApp gateway vs accessibility APIs: pick by detection surface.

Because that is where Meta has end-to-end observability into your code's behavior. When Baileys, whatsmeow, or any other library opens a Noise-encrypted socket to mmg.whatsapp.net and claims to be a linked device, every send, every read receipt, every typing indicator, every contact sync travels through that socket. Meta's anti-automation models score that traffic on cadence, reply ratio, identical-content fan-out, time-of-day distribution, and contact-graph distance. Multiple open issue threads on Baileys (issues/1869, issues/2309) and on whatsmeow (issue/810) document bans landing within hours of scanning a QR, especially on new numbers or accounts that immediately message strangers. The fix the community converged on is anti-ban middleware that emulates human cadence (kobie3717/baileys-antiban). That entire detection model does not apply to the accessibility-API path, because no socket leaves your process. The WhatsApp app itself opens the only socket, and that socket carries one human user's normal traffic.

Nothing that did not already exist before you installed it. The flow: AXUIElementCreateApplication grabs a handle to the running WhatsApp app. AXUIElementCopyAttributeValue reads kAXRoleAttribute, kAXDescriptionAttribute, kAXValueAttribute, kAXTitleAttribute, kAXPositionAttribute, kAXSizeAttribute, kAXChildrenAttribute from each element. The traversal walks to a max depth of 15. That is the same data macOS exposes to VoiceOver so a blind user can navigate the same app. It is a local in-process call to the macOS Accessibility framework. There is no IPC to Meta, no protocol packet, no remote attestation hook the WhatsApp app could use to detect that it is being read. When the server pastes text and presses Return, it does so via CGEvent (the same path keyboard shortcuts take) and Cmd+V (the OS clipboard). The WhatsApp app receives a keystroke, formats it as a normal outgoing message, and sends it through its own protocol the way it always does.

Two real reasons. First, portability: Baileys runs on a $5 Linux box, Evolution API runs in Docker, both run on infrastructure teams already operate. The accessibility path needs a Mac, which is an awkward production deployment. Second, throughput: a Baileys session can in principle push hundreds of messages per minute through the protocol; the accessibility path is hard-capped near 15 per minute per Mac because it is driving one focused UI. For multi-tenant SaaS sending opted-in transactional or marketing messages, neither limit fits and the right answer is Meta's official Cloud API. For personal-account automation, solo-founder inbound routing, or an AI agent triaging your own messages, Mac plus accessibility wins on the only axis that matters there: not getting your number banned. Pick by your actual constraint, not by which option is more famous.

Sources/WhatsAppMCP/main.swift in the open repo at github.com/m13v/whatsapp-mcp-macos. The traverseAXTree function (around lines 118-176) creates an AXUIElement for the WhatsApp process, sets a 5-second messaging timeout, and recursively walks children up to depth 15. For every element it captures role, description, value, title, and CGRect (position + size). Roles it explicitly keeps even without text are AXButton, AXTextField, AXTextArea, AXStaticText, AXHeading, AXGenericElement, AXLink. The send-side code (handleSendMessage, around lines 888-958) runs this traversal twice per outbound: once to find the compose AXTextArea, once to verify a 'Your message, ' bubble appeared after Return. Both traversals are local; nothing leaves the machine.

Better than running it without, but the model is still adversarial. Anti-ban middleware (e.g. kobie3717/baileys-antiban) emulates human cadence, rate-limits sends, ramps new numbers across days, and pauses when health checks see 403s. It moves the median session lifetime from hours to weeks for accounts doing reasonable volume. It does not change the underlying truth that Meta's ML is scoring your socket. Treat a Baileys account as disposable: design for the case where it gets logged out, plan a re-pair path, and never put your personal number on it. The accessibility path is a different choice with different tradeoffs: you keep your personal number safe but accept macOS hardware and the 15/min ceiling.

Not really, at the protocol level. wuzapi and wppconnect-server wrap whatsmeow and Baileys respectively, so they inherit the same detection surface. green-api hosts the connection on their infrastructure (sometimes a Cloud API-flavored offering, sometimes Baileys-flavored behind their REST), so the risk depends on which side they actually use; their unofficial tier is fundamentally the same as self-hosting Baileys. whatsapp-web.js and venom-bot drive automated whatsapp-web.com via Puppeteer, which is a different surface but one Meta also monitors closely. The honest grouping: any gateway whose architecture is 'open a session pretending to be a real client' lives on the same detection surface, regardless of which library is under it.

Yes, and it is a common shape. One MCP entry pointing at the local accessibility-driven server on the Mac handles personal-account work: drafting replies, reading group chats, inbox triage. A second MCP entry (HTTP) wrapping Evolution API or Baileys on a Linux box handles disposable-account outbound where ban risk is acceptable. The agent picks based on which account should send. The two paths target different sending identities and different volume profiles, so they do not step on each other. If you want a third lane for verified-business sending, plug Meta's Cloud API in as a third MCP entry; see the /alternative/whatsapp-desktop-vs-cloud-api page on this site for that comparison.

The mechanism is not the policy lever. The Accessibility framework on macOS is the same surface VoiceOver uses; using it to read and write the WhatsApp window is no different from a screen reader user navigating the app. What WhatsApp's consumer terms care about is the activity: a personal account having normal conversations with normal contacts is sanctioned no matter how the typing happens; a personal account mass-messaging strangers or behaving like a business is the kind of activity that triggers enforcement no matter how the typing happens. The Business API exists for business-shaped use cases. Read the consumer terms at https://www.whatsapp.com/legal/terms-of-service before pushing volume on any path.

Install: npm install -g whatsapp-mcp-macos. Grant Accessibility permission to the binary in System Settings > Privacy & Security > Accessibility. Add a stdio entry to your MCP host (Claude Desktop, Cursor, Windsurf) pointing at the installed binary. Restart the host. Then in your agent: whatsapp_start, whatsapp_search('matt'), whatsapp_open_chat({index: 0}), whatsapp_send_message('hello'). The send returns synchronously with verified:true once the bubble appears. Total wall-clock from install to first verified send is usually under five minutes; the only step that takes user judgment is the Accessibility permission grant.