Skip to content

Add WhatsApp pairing code login (--phone flag)#83482

Closed
buggy324234 wants to merge 1 commit into
openclaw:mainfrom
buggy324234:feature/whatsapp-pairing-code
Closed

Add WhatsApp pairing code login (--phone flag)#83482
buggy324234 wants to merge 1 commit into
openclaw:mainfrom
buggy324234:feature/whatsapp-pairing-code

Conversation

@buggy324234

@buggy324234 buggy324234 commented May 18, 2026

Copy link
Copy Markdown

Summary

  • Adds --phone flag to openclaw channels login for WhatsApp pairing code authentication
  • Uses Baileys' requestPairingCode() as an alternative to QR code scanning
  • Falls back to QR if pairing code request fails

Motivation

QR code scanning requires a second device, which blocks automated/headless deployment flows and mobile-first onboarding (e.g., deploying OpenClaw from a WhatsApp conversation where the user can't scan a QR displayed on the same phone).

Pairing codes let users link WhatsApp by entering an 8-digit code in WhatsApp > Linked Devices > "Link with phone number instead" — no second device needed.

Usage

openclaw channels login --channel whatsapp --phone +353830836798

Output:

Enter this pairing code in WhatsApp > Linked Devices > Link with phone number:

  A7K2-M9X4

Changes

  • extensions/whatsapp/src/session.ts — Accept phoneNumber option, call requestPairingCode() when QR is generated and phone number is provided
  • extensions/whatsapp/src/login.ts — Add phoneNumber parameter to loginWeb()
  • extensions/whatsapp/src/channel.ts — Pass phoneNumber from auth login callback
  • src/cli/channels-cli.ts — Add --phone option to channels login command
  • src/cli/channel-auth.ts — Thread phoneNumber through auth options
  • src/channels/plugins/types.adapters.ts — Add phoneNumber to ChannelAuthAdapter type

Test plan

  • openclaw channels login --channel whatsapp still works with QR (no regression)
  • openclaw channels login --channel whatsapp --phone +<number> generates pairing code
  • Code entry in WhatsApp app successfully links the device
  • Falls back to QR if requestPairingCode() fails

🤖 Generated with Claude Code

@buggy324234 @claude
Add WhatsApp pairing code support as alternative to QR scanning
cd70481 
Adds --phone flag to `openclaw channels login` that uses Baileys'
requestPairingCode() to generate an 8-digit code instead of a QR.
Users enter the code in WhatsApp > Linked Devices > Link with phone number.

This enables WhatsApp linking without a second device for QR scanning,
which is critical for automated/headless deployment flows.

Usage:
  openclaw channels login --channel whatsapp --phone +353830836798

Changes:
- session.ts: Accept phoneNumber option, call requestPairingCode() when
  QR is generated and phone number is provided, fall back to QR on error
- login.ts: Add phoneNumber parameter to loginWeb(), normalize phone format
- channel.ts: Pass phoneNumber from auth login callback to loginWeb()
- channels-cli.ts: Add --phone option to `channels login` command
- channel-auth.ts: Add phoneNumber to ChannelAuthOptions, pass through
- types.adapters.ts: Add phoneNumber to ChannelAuthAdapter login params

Co-Authored-By: Claude Opus 4.6 (1M context) <[email protected]>
@openclaw-barnacle openclaw-barnacle Bot added channel: whatsapp-web Channel integration: whatsapp-web cli CLI command changes size: XS triage: needs-real-behavior-proof Candidate: external PR needs after-fix proof from a real setup. labels May 18, 2026
@clawsweeper

clawsweeper Bot commented May 18, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Codex review: needs real behavior proof before merge.

Workflow note: Future ClawSweeper reviews update this same comment in place.

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.

Summary
The PR adds a --phone option to openclaw channels login, threads phoneNumber through channel auth, and changes WhatsApp login to request a Baileys pairing code with QR fallback.

Reproducibility: no. not for a bug reproduction; this is a new login capability. The PR has an unchecked test plan and no live WhatsApp evidence showing the after-fix behavior.

PR rating
Overall: 🧂 unranked krab
Proof: 🧂 unranked krab
Patch quality: 🧂 unranked krab
Summary: The feature direction is plausible, but missing real behavior proof plus sensitive logging and core API-boundary issues make the PR not merge-ready.

Rank-up moves:

  • Remove pairing code and phone number from persistent logs.
  • Redesign the phone input as a WhatsApp-owned or plugin-declared auth option rather than a generic core adapter field.
  • Add redacted real WhatsApp pairing proof plus focused tests for QR fallback and pairing-code output.
What the crustacean ranks mean
  • 🦀 challenger crab: rare, exceptional readiness with strong proof, clean implementation, and convincing validation.
  • 🦞 diamond lobster: very strong readiness with only minor maintainer review expected.
  • 🐚 platinum hermit: good normal PR, likely mergeable with ordinary maintainer review.
  • 🦐 gold shrimp: useful signal, but proof or patch confidence is still limited.
  • 🦪 silver shellfish: thin signal; proof, validation, or implementation needs work.
  • 🧂 unranked krab: not merge-ready because proof is missing/unusable or there are serious correctness or safety concerns.
  • 🌊 off-meta tidepool: rating does not apply to this item.

Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics.

Real behavior proof
Needs real behavior proof before merge: The PR body only has an unchecked test plan; before merge, the contributor should add redacted terminal output, copied live output, logs, screenshots, or a recording showing the real --phone WhatsApp link flow, then update the PR body or ask a maintainer to comment @clawsweeper re-review.

Risk before merge
Why this matters: - The PR body contains only an unchecked manual test plan, so there is no after-fix proof that a real WhatsApp account can link through the new pairing-code flow or still falls back to QR correctly.

  • Merging as written would persist a transient WhatsApp pairing code and the supplied phone number in logs, which is a security and privacy regression.
  • The --phone flag and phoneNumber adapter field make the generic core channel login surface WhatsApp-specific unless maintainers intentionally choose that product/API direction.

Maintainer options:

  1. Revise Before Merge (recommended)
    Require a branch update that removes sensitive pairing-code logging, resolves the core/plugin auth-option boundary, and adds focused coverage before maintainers consider the feature.
  2. Post Real WhatsApp Proof
    Ask the contributor for redacted terminal output, logs, screenshots, or a short recording showing --phone generating a pairing code and successfully linking a WhatsApp device.
  3. Accept Core Flag Deliberately
    Maintainers could intentionally accept a WhatsApp-specific global login flag, but that should be an explicit API decision rather than incidental plumbing in this PR.

Next step before merge
This needs contributor real-behavior proof and maintainer/API-boundary judgment before an automated repair lane would be useful.

Security
Needs attention: The diff introduces a concrete logging leak for WhatsApp pairing-code authentication material.

Review findings

  • [P1] Avoid logging pairing credentials — extensions/whatsapp/src/session.ts:198
  • [P2] Keep WhatsApp options out of the generic auth contract — src/channels/plugins/types.adapters.ts:368
Review details

Best possible solution:

Keep pairing-code login in a WhatsApp-owned or plugin-declared auth-options surface, redact transient pairing data from logs, cover QR and pairing paths with focused tests, and require redacted live WhatsApp proof before merge.

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

No, not for a bug reproduction; this is a new login capability. The PR has an unchecked test plan and no live WhatsApp evidence showing the after-fix behavior.

Is this the best way to solve the issue?

No, not as written. Baileys supports pairing-code login, but this implementation logs sensitive material and adds a WhatsApp-only field to the generic channel auth surface instead of using a clean plugin-owned or plugin-declared option path.

Label justifications:

  • P2: This is a normal-priority feature PR with limited blast radius, but it has merge-blocking security and API-boundary issues.
  • merge-risk: 🚨 security-boundary: The diff logs a WhatsApp pairing code and phone number, which could expose transient linking material and private contact data after merge.

Full review comments:

  • [P1] Avoid logging pairing credentials — extensions/whatsapp/src/session.ts:198
    requestPairingCode() returns the code the user enters to link WhatsApp, but this logs both that code and the supplied phone number through sessionLogger.info. Those logs can persist transient auth material outside the interactive prompt, so keep the code only in the user-facing runtime output and log a redacted event instead.
    Confidence: 0.92
  • [P2] Keep WhatsApp options out of the generic auth contract — src/channels/plugins/types.adapters.ts:368
    Adding phoneNumber to ChannelAuthAdapter makes the core channel-login contract carry a WhatsApp-only input, and the matching global --phone flag is silently irrelevant for other channels. Please move this behind a plugin-owned or plugin-declared auth option surface so core stays channel-agnostic and other plugins do not inherit a no-op phone field.
    Confidence: 0.86

Overall correctness: patch is incorrect
Overall confidence: 0.88

Security concerns:

  • [high] Pairing code and phone number are logged — extensions/whatsapp/src/session.ts:198
    The PR writes the generated pairing code and normalized phone number to sessionLogger.info; the code is transient auth material and the phone number is private user data, so logs should be redacted.
    Confidence: 0.92

What I checked:

  • Current WhatsApp login docs are QR-only: Current main documents openclaw channels login --channel whatsapp under Link WhatsApp (QR) and has no documented pairing-code login path. Public docs: docs/channels/whatsapp.md. (docs/channels/whatsapp.md:63, 322f0bb7bc0a)
  • Current generic CLI/auth contract has no phone option: The main branch channels login command exposes only channel/account/verbose, and ChannelAuthAdapter.login only carries generic channel auth inputs. (src/cli/channels-cli.ts:254, 322f0bb7bc0a)
  • Dependency contract check: Baileys documents pairing-code login as requestPairingCode(number) when creds are not registered, with phone numbers containing digits and country code only; the upstream socket source stores the pairing code in auth state and returns it.
  • PR logs transient auth material: The PR head writes both the normalized phone number and the returned pairing code through sessionLogger.info, which can persist WhatsApp linking material outside the interactive prompt. (extensions/whatsapp/src/session.ts:198, cd70481b184f)
  • Restart path currently carries only QR state: The existing WhatsApp login restart path recreates the socket with only authDir, socket timing, and onQr; pairing-code state would need an explicit design if the pairing-code flow must survive the code-515 restart path. (extensions/whatsapp/src/connection-controller.ts:221, 322f0bb7bc0a)
  • History and routing signal: The available blame/log history for the central WhatsApp login/session and channel auth surfaces points to commit cd15ce3 as the current-main implementation snapshot. (extensions/whatsapp/src/session.ts:131, cd15ce35a0ee)

Likely related people:

  • Ayaan Zaidi: Current-main blame and git log -S for WhatsApp session/login and channel auth surfaces all point to commit cd15ce3 in the available checkout history. (role: recent area contributor; confidence: medium; commits: cd15ce35a0ee; files: extensions/whatsapp/src/session.ts, extensions/whatsapp/src/login.ts, extensions/whatsapp/src/channel.ts)

Codex review notes: model gpt-5.5, reasoning high; reviewed against 322f0bb7bc0a.

@clawsweeper clawsweeper Bot added rating: 🧂 unranked krab Not merge-ready due to missing proof or serious correctness/safety concerns. status: 📣 needs proof The PR needs real behavior proof before ClawSweeper can clear the contributor ask. P2 Normal backlog priority with limited blast radius. merge-risk: 🚨 security-boundary 🚨 May affect sandboxing, authorization, credentials, or sensitive data. labels May 18, 2026
@buggy324234
buggy324234 deleted the feature/whatsapp-pairing-code branch May 18, 2026 07:20
This was referenced Jun 19, 2026
Open
Closed
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Labels

channel: whatsapp-web Channel integration: whatsapp-web cli CLI command changes merge-risk: 🚨 security-boundary 🚨 May affect sandboxing, authorization, credentials, or sensitive data. P2 Normal backlog priority with limited blast radius. rating: 🧂 unranked krab Not merge-ready due to missing proof or serious correctness/safety concerns. size: XS status: 📣 needs proof The PR needs real behavior proof before ClawSweeper can clear the contributor ask. triage: needs-real-behavior-proof Candidate: external PR needs after-fix proof from a real setup.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@buggy324234