WhatsApp Pairing fails

[karkarl]

WhatsApp pairing fails on latest release version v0.6.12, windows x64

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed July 13, 2026, 7:21 PM ET / 23:21 UTC.

Summary
Keep this reopened issue open: the v0.6.12 first-use WhatsApp pairing path remains credibly blocked, no merged fix or canonical replacement is linked, and the prior source review found that Windows offers QR linking when the connected gateway has no loaded web-login provider, then exposes an internal exception rather than actionable recovery.

Reproducibility: yes. at source level: use v0.6.12 or current main with a connected gateway that does not expose a loaded WhatsApp web-login provider, then start WhatsApp QR pairing from the Windows channel surface. A fresh runtime reproduction should still confirm the exact gateway package state and capture redacted diagnostics.

Next step
A maintainer should coordinate gateway provider/package diagnosis with the Windows capability gate and recovery UX before assigning a bounded implementation, because a Windows-only repair cannot prove provider availability across managed and external gateways.

Maintainer decision needed

• Question: What cross-component proof is required to resolve this issue across managed Windows gateways and externally managed gateways?
• Rationale: The Windows client owns discoverability and recovery UX, while actual WhatsApp web-login availability is controlled by gateway plugin/package loading; resolution needs an agreed proof boundary covering both sides.
• Likely owner: shanselman — The decision spans Windows setup, gateway connectivity, and Command Center channel UX, which align most closely with his repository history.
• Options:
  • Prove both gateway modes (recommended): Require successful QR pairing with a provider-present gateway plus graceful Doctor/Fix recovery for a provider-missing managed or external gateway.
  • Ship Windows recovery first: Accept capability gating and actionable recovery in Windows while tracking provider packaging or loading as separate gateway work.
  • Treat as gateway-only: Keep the Windows pairing surface unchanged and resolve only the gateway package/provider loading failure.

Review details

Best possible solution:

Make WhatsApp pairing capability-driven: verify the connected gateway exposes the required web-login provider before enabling QR linking, complete normal pairing when available, and otherwise show a Doctor/Fix flow that diagnoses provider loading and gives gateway-appropriate recovery without exposing an internal exception.

Do we have a high-confidence way to reproduce the issue?

Yes at source level: use v0.6.12 or current main with a connected gateway that does not expose a loaded WhatsApp web-login provider, then start WhatsApp QR pairing from the Windows channel surface. A fresh runtime reproduction should still confirm the exact gateway package state and capture redacted diagnostics.

Is this the best way to solve the issue?

No implementation has been proposed yet; the narrow maintainable solution is to combine provider-capability gating and in-product recovery with a gateway-side provider-loading diagnosis, rather than merely hiding the exception or retrying blindly.

AGENTS.md: found and applied where relevant.

Remaining risk / open question:

• The report does not identify whether the failing gateway is managed by the Windows setup flow or is an external gateway, so the package/loading root cause may differ by deployment.
• A Windows-only UI repair can prevent the internal exception and guide recovery, but it cannot by itself restore a missing or unloaded WhatsApp web-login provider on every gateway.
• Closing before proving both provider-present pairing and provider-missing recovery would leave the first-use release blocker unresolved.

Codex review notes: model internal, reasoning high; reviewed against 77c42440376e.

Label changes

Label justifications:

• P0: A non-technical user on the latest release is blocked from completing an advertised first-use WhatsApp pairing workflow and receives no usable in-product recovery.
• impact:ux-release-blocker: Completing or recovering pairing currently requires gateway/provider diagnosis outside the visible Windows flow rather than an in-product path forward.

Evidence reviewed

What I checked:

• Release reproduction: The reporter identifies Windows x64 release v0.6.12 and provides a screenshot of the failed pairing flow; the report targets the latest published release rather than an obsolete version. (4166e0fd63f8)
• Current-main source assessment: The previous ClawSweeper source review found that the Windows UI advertises WhatsApp QR linking without first establishing that the connected gateway loaded a compatible web-login provider; no subsequent linked fix is present in the supplied GitHub context. (src/OpenClaw.Tray.WinUI/Pages/ChannelsPage.xaml.cs, 77c42440376e)
• Established product surface: Current main publicly presents channel control and WhatsApp status as supported Command Center functionality, so an unusable pairing action is broken established behavior rather than a request for a new channel capability. (README.md:436, 77c42440376e)
• Human reopening signal: After project triage and a temporary close, Samantha Song reopened the issue on July 13, 2026; this is recent human evidence that the item should not be swept closed as resolved.
• No canonical replacement: The supplied related-item and timeline context contains no merged closing PR, open fix PR, or same-repository canonical issue that owns the remaining failure.

Likely related people:

• shanselman: Repository and release history connect Scott Hanselman with the Windows tray, setup, gateway, and Command Center surfaces that converge in this pairing workflow. (role: feature owner and recent area contributor; confidence: medium; commits: 77c42440376e, 4166e0fd63f8; files: src/OpenClaw.Tray.WinUI/Pages/ChannelsPage.xaml.cs, src/OpenClaw.Tray.WinUI/Pages/ConnectionPage.xaml.cs, README.md)
• samanthamsong: Samantha Song added project metadata and deliberately reopened the issue after its temporary closure, making her the clearest current routing contact for the cross-component follow-up. (role: recent issue owner and likely follow-up coordinator; confidence: high)

How this review workflow works

• ClawSweeper keeps one durable marker-backed review comment per issue or PR.
• Re-runs edit this comment so the latest verdict, findings, and automation markers stay together instead of adding duplicate bot comments.
• A fresh review can be triggered by eligible @clawsweeper re-review comments, exact-item GitHub events, scheduled/background review runs, or manual workflow dispatch.
• PR/issue authors and users with repository write access can comment @clawsweeper re-review or @clawsweeper re-run on an open PR or issue to request a fresh review only.
• Maintainers can also comment @clawsweeper review to request a fresh review only.
• Fresh-review commands do not start repair, autofix, rebase, CI repair, or automerge.
• Maintainer-only repair and merge flows require explicit commands such as @clawsweeper autofix, @clawsweeper automerge, @clawsweeper fix ci, or @clawsweeper address review.
• Maintainers can comment @clawsweeper explain to ask for more context, or @clawsweeper stop to stop active automation.