openclaw - 💡(How to fix) Fix [Bug]: WhatsApp channel login can stall before a usable terminal QR is exposed [2 comments, 3 participants]

Bug type

Regression (worked before, now fails)

Beta release blocker

No

Summary

WhatsApp channel re-authentication can enter the connection flow without reliably exposing a usable terminal QR through the active CLI runtime.

Steps to reproduce

1. Start OpenClaw 2026.4.29 from a source checkout.
2. Run openclaw channels login --channel whatsapp.
3. Observe the command entering the WhatsApp connection flow and printing "Waiting for WhatsApp connection..." without reliably exposing a usable terminal QR through the active CLI runtime.

Expected behavior

The WhatsApp login command should print the Linked Devices QR code through the active CLI runtime so it can be scanned from the invoking terminal.

Actual behavior

The command entered the WhatsApp connection flow and could appear stuck at "Waiting for WhatsApp connection..." without a usable terminal QR being exposed through the active CLI runtime.

OpenClaw version

2026.4.29

Operating system

Arch Linux

Install method

Source checkout / pnpm build / local CLI

Model

N/A

Provider / routing chain

N/A

Additional provider/model setup details

N/A

Logs, screenshots, and evidence

Observed terminal state: the WhatsApp login flow printed "Waiting for WhatsApp connection..." but did not reliably expose a usable terminal QR through the active CLI runtime.

Code-path evidence: QR rendering was tied to direct stdout/console output instead of the active RuntimeEnv writer, and explicit WhatsApp channel login was routed through broader channel/plugin startup machinery instead of a narrow bundled login path.

Verification evidence after fix: targeted CLI/channel/WhatsApp tests passed, and manual smoke verification confirmed WhatsApp send worked after re-authentication.

Impact and severity

Affected: WhatsApp channel login/re-authentication through the OpenClaw CLI. Severity: High for affected WhatsApp onboarding or re-authentication attempts because the QR is required to complete login. Frequency: Observed during the reported re-authentication attempt Consequence: WhatsApp login can require manual retry/debugging before the QR can be scanned.

Additional information

The fix routes explicit bundled WhatsApp login through a narrower login path, writes terminal QR output through the active runtime writer when available, and reduces unnecessary plugin/config startup work for channel login/logout.

Fix approach:

• Route explicit bundled WhatsApp login through the narrow WhatsApp login runtime instead of the broader channel runtime.
• Pass the active RuntimeEnv into WhatsApp socket creation for terminal QR rendering.
• Write the QR heading and ASCII QR through RuntimeEnv.writeStdout when available, with fallback to runtime logging/stdout.
• Mark channels login/logout as minimal startup commands that bypass config guard and avoid plugin loading.
• Load only the configured-channel registry when channel auth needs to infer a channel from config.
• Add regression coverage for runtime-routed terminal QR output and channel auth startup policy.
• Refresh the local Baileys compatibility patch for the current WhatsApp Web version and unified_session behavior observed during pairing/login. @dougvk Comment