Best possible solution:

Consolidate on the typed login-method implementation, prepare every replacement socket for a fresh code, fail closed when detected partial auth cannot be safely cleared, and carry the contributor's physical-device proof onto the final canonical head.

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

Yes for the introduced retry defect from source: trigger the existing 408 timeout recovery after the initial phone code, and the replacement socket is installed without another requestPairingCode call. This read-only review did not run a live timeout scenario.

Is this the best way to solve the issue?

No. The happy path is real-device proven, but the best solution uses the typed shared login-method contract, prepares every replacement socket, and stops rather than continuing when detected partial auth cannot be cleared safely.

Full review comments:

• [P1] Request a fresh code on timeout replacement sockets — extensions/whatsapp/src/login.ts:234-236
  The code requests a pairing code only on the initial socket. waitForWhatsAppLoginResult can replace that socket after a 408 timeout, but this callback only updates the reference, so the replacement waits without ever presenting a new code. Prepare each replacement socket and call requestPairingCode again before waiting.
  Confidence: 0.98
• [P2] Surface refused stale-credential cleanup — extensions/whatsapp/src/login.ts:197-201
  The cleanup helper returns the same false value when no cleanup is needed and when detected partial state cannot be removed safely. The caller therefore continues in the latter case with the stale state it intended to remove; return a closed result that distinguishes these cases and fail with an actionable error when cleanup is refused.
  Confidence: 0.92

Overall correctness: patch is incorrect
Overall confidence: 0.94

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning high; reviewed against 6595d1756b1a.

Label changes:

• add rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦞 diamond lobster and patch quality is 🦐 gold shrimp.
• add status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Sufficient (live_output): The PR body provides after-fix physical Android pairing evidence, observed pairing and restart logs, and final linked healthy status with private identifiers redacted.
• remove rating: 🐚 platinum hermit: Current PR rating is rating: 🦐 gold shrimp, so this older rating label is no longer current.
• remove status: 👀 ready for maintainer look: Current PR status label is status: ⏳ waiting on author.

Label justifications:

• P2: This is a valuable but bounded WhatsApp onboarding feature whose retry defects block merge without creating an urgent current-main regression.
• merge-risk: 🚨 compatibility: The PR changes a public CLI contract and shared plugin auth API while a different typed permanent contract is under maintainer review.
• merge-risk: 🚨 auth-provider: The timeout recovery path can replace the login socket without generating a usable new authentication code.
• merge-risk: 🚨 session-state: The patch reclassifies and conditionally deletes persisted WhatsApp pairing credentials but cannot reliably surface refused cleanup.
• rating: 🦐 gold shrimp: Overall readiness is 🦐 gold shrimp; proof is 🦞 diamond lobster and patch quality is 🦐 gold shrimp.
• status: ⏳ waiting on author: ClawSweeper has contributor-facing work open and is waiting for author action. Sufficient (live_output): The PR body provides after-fix physical Android pairing evidence, observed pairing and restart logs, and final linked healthy status with private identifiers redacted.
• proof: sufficient: Contributor real behavior proof is sufficient. The PR body provides after-fix physical Android pairing evidence, observed pairing and restart logs, and final linked healthy status with private identifiers redacted.

PR surface:

Source +343, Tests +229, Docs +26. Total +598 across 22 files.

What I checked:

• Real-device proof: The PR body documents a physical Android phone accepting the generated code, observed 515 recovery logs, and a final linked, healthy, connected channel state. (24f18c05bee1)
• Timeout replacement gap: The initial socket receives requestPairingCode, but the timeout recovery callback only assigns the replacement socket and never prepares it or requests another code. (extensions/whatsapp/src/login.ts:234, 24f18c05bee1)
• Upstream socket contract: Baileys 7.0.0-rc13 emits connecting for each created socket, while requestPairingCode writes pairing identity and code into that socket's auth state; a replacement therefore needs its own request. (extensions/whatsapp/package.json:12, 24f18c05bee1)
• Competing canonical implementation: The maintainer-authored replacement adds a typed channel login method, per-replacement socket preparation, cleanup failure handling, and focused retry tests, but explicitly reports no live physical-device pairing proof. (src/channels/plugins/channel-login-method.types.ts:1, 7d80bcfbf96c)
• Feature history: Current WhatsApp login and auth behavior was shaped by lifecycle, 515 recovery, auth detection, credential security, and plugin-boundary changes, indicating shared historical ownership. (extensions/whatsapp/src/login.ts:1, aa023e428306)

Likely related people:

• mcaxtr: Authored the maintainer-labeled replacement for the same canonical issue and added the typed API, timeout replacement, and credential-safety hardening relevant here. (role: replacement implementation owner; confidence: high; commits: d9b765828b60, 312acae88161, aa7a6ea82c62; files: src/channels/plugins/channel-login-method.types.ts, src/plugin-sdk/channel-contract.ts, extensions/whatsapp/src/login.ts)
• steipete: Authored major merged WhatsApp auth detection, identity handling, plugin SDK boundary, and channel architecture changes around the affected paths. (role: feature-history owner; confidence: high; commits: 6320f739d4e7, 3b6d980c52c3, 9ebe38b6e36b; files: extensions/whatsapp/src/auth-store.ts, src/channels/plugins/types.adapters.ts)
• Jason: Implemented the merged WhatsApp 515 pairing recovery behavior that the new phone-code flow reuses and must preserve. (role: adjacent behavior contributor; confidence: medium; commits: 9d3e653ec9d2; files: extensions/whatsapp/src/login.ts, extensions/whatsapp/src/connection-controller.ts)

• 🦀 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.

• 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.

• reviewed 2026-06-24T16:18:29.063Z sha c217d0e :: needs maintainer review before merge. :: none

• Eggs appear after the PR passes real-behavior proof. It is here for vibes, not verdicts: it does not change labels, ratings, merge decisions, or automation.
• The shell reacts to review momentum: open follow-up work warms it up, re-review makes it wobble, and a clean final review lets it hatch.
• Hatchability usually comes from sufficient real-behavior proof, no blocking P0/P1/P2 findings, no security attention needed, and clean correctness. A merged PR is already final, so merge makes the egg hatchable independently.
• The hatch is seeded from this repository and PR number, so the same PR keeps the same creature; the reviewed head SHA can only change safe visual details.
• Rarity is just collectible sparkle: 🥚 common, 🌱 uncommon, 💎 rare, ✨ glimmer, and 🌈 legendary.