Summary

During a field WhatsApp relink, the phone accepted the linked-device code but stayed on WhatsApp's native Logging in... screen. OpenClaw did not become healthy until the gateway was restarted while the phone was still in that state. After restart, OpenClaw observed the existing recovery path:

WhatsApp asked for a restart after pairing (code 515); waiting for creds to save…
WhatsApp Web connected.
Linked after restart; web session ready.

This looks related to prior reports where QR or linked-device scanning succeeds but the session never fully transitions to connected.

Related PR for phone-code pairing fallback: #85866
Related phone-code/headless issue: #85867

Repro shape observed

1. Start a WhatsApp login attempt on the gateway host.
2. Use the phone's linked-device flow and enter the code.
3. The phone accepts the code but remains on Logging in....
4. Status remains not fully connected / unhealthy until the gateway is restarted.
5. Restarting the gateway during that phone-side Logging in... phase lets the 515 restart path finish credential persistence and the web session becomes connected.

Workaround sequence that worked

openclaw channels login --channel whatsapp --account <account> --phone-number <country-code-and-number>
# enter the printed code on the phone under WhatsApp > Linked Devices > Link with phone number
# if the phone stays on Logging in... and the gateway logs mention 515:
openclaw gateway restart
openclaw channels status --channel whatsapp --account <account> --probe

Expected final status after the workaround: linked, healthy, running, connected.

Notes

• A preserved-data WhatsApp reinstall on the Android phone did not by itself complete the link; the gateway restart during the phone's Logging in... phase was the decisive step in this run.
• A partial phone-code auth attempt can leave stale incomplete credentials. Retry flows should avoid treating that partial state as a linked session and should clear it before starting a fresh login when the auth directory is owned by OpenClaw.
• This issue is meant to document the operational sequence; the code PR focuses on adding phone-code login and partial-credential cleanup rather than changing the broader 515 restart recovery behavior.