PR #67866: fix: guard .trim() on undefined prompter values in WhatsApp personal phone setup

• Repository: openclaw/openclaw
• Author: kagura-agent
• State: closed | merged: False
• Link: https://github.com/openclaw/openclaw/pull/67866

Description (problem / solution / changelog)

Fixes #67837

Problem: WhatsApp personal phone setup crashes with TypeError: Cannot read properties of undefined (reading 'trim') after entering a valid phone number. The prompter can return undefined for optional fields, but .trim() was called without null guards.

Fix: Added null/undefined guards before .trim() calls in setup-finalize.ts, similar to the fixes in #67489 and #67525.

Tests: Added test coverage for the case where prompter returns undefined values.

Changed files

• extensions/whatsapp/src/channel.setup.test.ts (modified, +49/-0)
• extensions/whatsapp/src/setup-finalize.ts (modified, +4/-4)

PR #67895: fix(whatsapp): guard setup prompt values

• Repository: openclaw/openclaw
• Author: lawrence3699
• State: closed | merged: True
• Link: https://github.com/openclaw/openclaw/pull/67895

Description (problem / solution / changelog)

Summary

AI-assisted: prepared with Codex.

• Problem: WhatsApp personal-phone and allowlist setup paths could crash with TypeError when a text prompt result surfaced as undefined at runtime.
• Why it matters: this breaks a real user-facing setup flow and blocks channel onboarding.
• What changed: normalize/guard prompt text before trimming/parsing in extensions/whatsapp/src/setup-finalize.ts, and add focused regression tests.
• What did NOT change (scope boundary): this does not change WhatsApp setup semantics, validation rules, or the shared wizard/prompt infrastructure.

Change Type (select all)

• Bug fix
• Feature
• Refactor required for the fix
• Docs
• Security hardening
• Chore/infra

Scope (select all touched areas)

• Gateway / orchestration
• Skills / tool execution
• Auth / tokens
• Memory / storage
• Integrations
• API / contracts
• UI / DX
• CI/CD / infra

Linked Issue/PR

• Closes #67837
• Related #67866
• This PR fixes a bug or regression

Root Cause (if applicable)

• Root cause: prompter.text(...) is typed as returning Promise<string>, but the WhatsApp finalize flow assumed that contract too strongly and called .trim() / splitSetupEntries(...) on prompt results without guarding against undefined.
• Missing detection / guardrail: there was no regression coverage for undefined prompt results in the extension-specific WhatsApp finalize path.
• Contributing context (if known): similar undefined.trim() bugs have appeared in other setup flows, but this extension-owned finalize path still had two unguarded prompt-result call sites.

Regression Test Plan (if applicable)

• Coverage level that should have caught this:
  • Unit test
  • Seam / integration test
  • End-to-end test
  • Existing coverage already sufficient
• Target test or file:
  • extensions/whatsapp/src/channel.setup.test.ts
• Scenario the test should lock in:
  • personal-phone setup does not crash on an undefined text result
  • allowlist-number entry does not crash on an undefined text result
• Why this is the smallest reliable guardrail:
  • the failure is in the extension-local finalize logic, so the narrowest trustworthy coverage is the existing WhatsApp setup test file around that logic.
• Existing test that already covers this (if any): none for undefined prompt results.
• If no new test is added, why not: N/A

User-visible / Behavior Changes

• WhatsApp setup no longer crashes with raw TypeError: Cannot read properties of undefined when those text prompt results come back undefined.
• In those invalid runtime cases, the flow now raises explicit validation-style errors (Invalid WhatsApp owner number / Invalid WhatsApp allowFrom list) instead.

Diagram (if applicable)

N/A

Security Impact (required)

• New permissions/capabilities? (Yes/No) No
• Secrets/tokens handling changed? (Yes/No) No
• New/changed network calls? (Yes/No) No
• Command/tool execution surface changed? (Yes/No) No
• Data access scope changed? (Yes/No) No
• If any Yes, explain risk + mitigation:

Repro + Verification

Environment

• OS: macOS 15.x
• Runtime/container: Node 24.14.0 via nvm, pnpm 10.32.1
• Model/provider: N/A
• Integration/channel (if any): WhatsApp setup finalize flow
• Relevant config (redacted): empty config {} with default WhatsApp account in direct reproduction

Steps

1. Run the finalize flow with a prompter that returns undefined for the WhatsApp personal-phone number.
2. Observe current main throw TypeError: Cannot read properties of undefined (reading 'trim') from extensions/whatsapp/src/setup-finalize.ts:140.
3. Run the sibling allowlist-number path with a prompter that returns undefined and observe TypeError: Cannot read properties of undefined (reading 'split') from splitSetupEntries(...) via extensions/whatsapp/src/setup-finalize.ts:330.

Expected

• The setup flow should not crash with raw TypeError when prompt text comes back undefined.
• Invalid runtime prompt results should be handled explicitly and predictably.

Actual

• Both branches crash on current main with raw TypeError before the setup flow can report a meaningful error.

Evidence

Attach at least one:

• Failing test/log before + passing after
• Trace/log snippets
• Screenshot/recording
• Perf numbers (if relevant)

Human Verification (required)

What you personally verified (not just CI), and how:

• Verified scenarios:
  • reproduced the personal-phone crash locally with a direct node --import tsx script against extensions/whatsapp/src/setup-finalize.ts
  • reproduced the sibling allowlist crash locally with the same direct path
  • verified the new regression tests pass in extensions/whatsapp/src/channel.setup.test.ts
• Edge cases checked:
  • personal-phone branch still passes with a normal phone number
  • allowlist branch still passes with normal comma-separated numbers via the existing test
  • rebased branch still passes the direct WhatsApp setup test file
• What you did not verify:
  • I did not run a live WhatsApp QR/linking flow end-to-end
  • I did not verify on Windows directly
  • codex review --base origin/main was attempted locally but was blocked by a Codex usage-limit error before completion

Review Conversations

• I replied to or resolved every bot review conversation I addressed in this PR.
• I left unresolved only the conversations that still need reviewer or maintainer judgment.

If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers.

Compatibility / Migration

• Backward compatible? (Yes/No) Yes
• Config/env changes? (Yes/No) No
• Migration needed? (Yes/No) No
• If yes, exact upgrade steps:

Risks and Mitigations

• Risk:
  • The allowlist branch now throws an explicit invalid-input error when the prompt result is empty/undefined instead of falling through to an empty allowFrom list.
  • Mitigation:
    • This matches the existing validation intent (Required) and is covered by the new regression test.

Changed files

• CHANGELOG.md (modified, +1/-0)
• extensions/whatsapp/src/channel.setup.test.ts (modified, +25/-0)
• extensions/whatsapp/src/setup-finalize.ts (modified, +14/-4)