Issue Station
Sign In
Tools hereToolbox

openclaw - ✅(Solved) Fix bug(control-ui): WhatsApp relink can stay stuck on logging in even when backend wait succeeds [1 pull requests, 1 participants]

Official PRs (…)
ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

Helpful · Quick feedback

Loading…
GitHub stats
openclaw/openclaw#63019•Fetched 2026-04-09 07:59:28
View on GitHub
Comments
0
Participants
1
Timeline
1
Reactions
0
Author
AytuncYildizliAytuncYildizli
Participants
AytuncYildizliAytuncYildizli
Timeline (top)
cross-referenced ×1

The OpenClaw Control UI WhatsApp relink flow can get stuck on logging in / couldn't link device even when the QR is accepted on the phone.

In our live local setup, web.login.start succeeds and emits a fresh QR, but the Control UI never appears to complete the follow-up wait/handoff reliably.

Root Cause

This makes WhatsApp relink look broken from the primary UI even though the backend can complete the link. Users see a failed relink and keep retrying, which is extremely confusing.

Fix Action

Workaround

After scanning the QR, manually run:

openclaw gateway call web.login.wait --params '{"timeoutMs":120000}' --timeout 130000 --json

This completed the link successfully in our repro when the UI was stuck.

PR fix notes

PR #63022: fix(whatsapp): keep control-ui relink in sync with QR rotation and scan wait

Description (problem / solution / changelog)

Summary

Keep the Control UI WhatsApp relink flow aligned with what the backend is actually doing.

This patch closes the gap where:

  • WhatsApp rotates QR refs during login but the active login state keeps the first QR
  • the Control UI can show logging in forever because it does not refresh the active QR or keep polling the wait path robustly enough after scan

What changed

Backend

  • refresh the active QR data when WhatsApp rotates refs during an in-flight login
  • preserve early QR emissions that arrive before the active login record is fully registered
  • keep the restart-after-515 path attached to the active wait promise

Control UI

  • teach waitWhatsAppLogin to poll and refresh the active QR while the login is still pending
  • clear the QR only after the backend confirms the link succeeded
  • add a targeted controller regression test for the QR-refresh wait loop

Why

In live use we saw this pattern repeatedly:

  1. open Channels -> WhatsApp -> Relink
  2. QR renders
  3. phone accepts the QR
  4. UI remains on logging in / eventually shows couldn't link device
  5. backend can still succeed if web.login.wait is called manually

So the relink flow was not only a QR-generation problem; it was a QR/wait/handoff synchronization problem.

Tests

Passing locally:

  • pnpm exec vitest run src/web/login-qr.test.ts

Not fully run:

  • ui/src/ui/controllers/channels.test.ts exists and matches the new controller behavior, but this repo's current vitest include list does not pick that file by default yet
  • full repo test/build matrix not run in this PR branch

Related

  • refs #48994
  • refs #63019

Changed files

  • src/web/auto-reply/deliver-reply.test.ts (modified, +59/-2)
  • src/web/auto-reply/deliver-reply.ts (modified, +41/-0)
  • src/web/login-qr.test.ts (modified, +44/-2)
  • src/web/login-qr.ts (modified, +35/-9)
  • ui/src/ui/controllers/channels.test.ts (added, +97/-0)
  • ui/src/ui/controllers/channels.ts (modified, +45/-11)

Code Example

openclaw gateway call web.login.wait --params '{"timeoutMs":120000}' --timeout 130000 --json

---

{
  "connected": true,
  "message": "✅ Linked! WhatsApp is ready."
}

---

openclaw gateway call web.login.wait --params '{"timeoutMs":120000}' --timeout 130000 --json
RAW_BUFFERClick to expand / collapse

Summary

The OpenClaw Control UI WhatsApp relink flow can get stuck on logging in / couldn't link device even when the QR is accepted on the phone.

In our live local setup, web.login.start succeeds and emits a fresh QR, but the Control UI never appears to complete the follow-up wait/handoff reliably.

What I observed

On macOS with a live local gateway:

  1. Open Control UI -> Channels -> WhatsApp
  2. Click Logout
  3. Click Relink / Show QR
  4. QR is shown and accepted by the phone
  5. UI enters logging in
  6. UI eventually says couldn't link device / couldn't connect

Live evidence

Gateway log shows the QR/start side works:

  • WhatsApp QR received.
  • web.login.start

But the UI flow does not reliably complete the second phase.

In the same environment, manually calling the backend wait method right after scanning succeeds:

openclaw gateway call web.login.wait --params '{"timeoutMs":120000}' --timeout 130000 --json

Result returned:

{
  "connected": true,
  "message": "✅ Linked! WhatsApp is ready."
}

So the QR/login backend path can finish, but the Control UI handoff gets stuck / fails to represent it correctly.

Why this matters

This makes WhatsApp relink look broken from the primary UI even though the backend can complete the link. Users see a failed relink and keep retrying, which is extremely confusing.

Related

  • refs #48994
  • refs #4686
  • refs #43316
  • refs #44190
  • refs #33961
  • refs #37801
  • refs #48658
  • refs #48703

Additional note

There may be two issues here:

  1. stale/rotated QR handling during the login window
  2. Control UI not driving or reflecting web.login.wait robustly enough after scan

Workaround

After scanning the QR, manually run:

openclaw gateway call web.login.wait --params '{"timeoutMs":120000}' --timeout 130000 --json

This completed the link successfully in our repro when the UI was stuck.

extent analysis

TL;DR

Manually calling the web.login.wait method after scanning the QR code can complete the WhatsApp relink flow when the Control UI is stuck.

Guidance

  • The issue may be caused by the Control UI not properly handling the web.login.wait method after the QR code is scanned, or by stale/rotated QR handling during the login window.
  • To verify the issue, check the gateway log for WhatsApp QR received and web.login.start messages to ensure the QR/login backend path is working.
  • Manually calling the web.login.wait method after scanning the QR code can be used as a temporary workaround to complete the link.
  • Investigate the Control UI code to determine why it is not driving or reflecting the web.login.wait method robustly enough after the scan.

Example

The following command can be used as a workaround:

openclaw gateway call web.login.wait --params '{"timeoutMs":120000}' --timeout 130000 --json

Notes

The root cause of the issue is unclear, and there may be two separate issues at play: stale/rotated QR handling and the Control UI not properly handling the web.login.wait method.

Recommendation

Apply the workaround by manually calling the web.login.wait method after scanning the QR code, as this has been shown to complete the link successfully in some cases.

Vote matrix · Quick signals

Works
Did the solution work? Tap to confirm.
Easy Fix
Was it a quick fix?
Time Saver
Did it save you time?
Blocking
Was it severely blocking?
Common Issue
Are others likely hitting this too?
Flaky / Intermittent
Is it intermittent?
Verified / Reproducible
Can you reproduce it reliably?
Loading…
#tokenizer error#prompt formatting#chain error#conversation history#tool integration

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

Back to top recommendations

TRENDING