openclaw - 💡(How to fix) Fix Title: [Feature Request] Social-Identity MFA: WhatsApp/Messaging-based Authentication Handshake

Summary

"Authenticate to the OpenClaw Control UI from any browser using a one-time code delivered via WhatsApp."

Problem to solve

Currently, accessing the OpenClaw Control UI from any machine other than the local device requires per-device SSH tunnel configuration, key management, and manual port forwarding — making remote access from phones, work machines, or new devices impractical. A WhatsApp-delivered OTP would allow any browser to authenticate without device-specific setup, leveraging an already-trusted and allowlisted channel that the gateway has open anyway.

Proposed solution

When a browser attempts to connect to the Control UI from an unrecognised device, the gateway sends a 6-digit one-time code via WhatsApp to the operator's allowlisted number. The user enters the code in the browser to complete authentication. The code expires after 60 seconds. Once approved, the device is paired and subsequent connections from that device proceed without re-verification. No per-device SSH configuration, key exchange, or authenticator app required. The WhatsApp channel already exists, is already authenticated to the operator's number, and is already trusted by the gateway — making it a natural second factor with zero additional setup.

Alternatives considered

TOTP (Google Authenticator/Authy) requires a separate app and per-device QR code scanning. SSH tunnels require per-device key setup and port forwarding knowledge, impractical on restricted networks or works machines. Tailscale requires installation and account authentication on every device. Token-based auth requires manual token distribution and rotation. Email OTP introduces a dependency on external mail infrastructure. All of these require either per-device configuration or additional tooling — WhatsApp leverages infrastructure the gateway already has open with an already-verified operator identity, making it the lowest-friction option that adds genuine security.

Impact

Affects any operator running OpenClaw on a home server or Mac Mini who needs to access the Control UI from a second device — phone, work machine, or any machine outside the local network. Currently blocks workflow entirely without significant manual setup. Occurs every time access is needed from a new or unrecognised device. Practical consequence is that the Control UI is effectively local-only for most users despite the gateway being designed for remote access. Severity escalates on restricted networks (corporate, mobile) where SSH tunneling is impractical or policy-prohibited. The WhatsApp channel is already open and trusted on any installation with WhatsApp enabled — implementing OTP delivery there requires no new infrastructure and resolves the friction for the common case of a single operator accessing their own gateway from multiple devices.

Evidence/examples

The device pairing flow already exists in the gateway — device.pair.list and device.pair.approve demonstrate the infrastructure for device trust decisions. The missing piece is a low-friction way to complete that approval from outside the local network without SSH access. The WhatsApp allowlist (channels.whatsapp.allowFrom) already encodes a verified operator identity — the number in that list is inherently trusted. Logs show repeated pairing-required rejections from remote devices (reason: not-paired) with no viable approval path available to a user without local SSH access. OpenClaw's own documentation defaults to SSH tunneling for remote access, acknowledging the gap. WhatsApp OTP for authentication is established prior art — WhatsApp Business API supports this use case commercially, and the pattern is well understood.

Additional information

The operator in this case is running OpenClaw on a sandboxed standard user account on an M1 Mac Mini, with the gateway exposed via Tailscale serve and SSH jump host. The WhatsApp channel is already allowlisted to a single number, making the trust boundary well-defined. The use case is a single-operator personal deployment — not a multi-user or enterprise scenario — which makes WhatsApp OTP particularly appropriate since the operator's number is the only trusted identity in the system. Implementation could be as lightweight as a temporary code stored in memory, generated on pairing request, delivered via the existing WhatsApp plugin, and validated in the handshake flow before device approval. No persistent storage or external service required beyond what the gateway already has running.