fix(sms): accept spaced prefixed phone numbers#111111
Conversation
Co-authored-by: chatgpt-codex-connector[bot] <199175422+chatgpt-codex-connector[bot]@users.noreply.github.com>
|
Codex review: needs maintainer review before merge. Reviewed July 18, 2026, 10:35 PM ET / July 19, 2026, 02:35 UTC. Summary PR surface: Source +3, Tests +4. Total +7 across 2 files. Reproducibility: yes. at source level: a spaced Review metrics: none identified. Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Next step before merge
Security Review detailsBest possible solution: Merge the focused SMS-local normalization repair after the normal current-head merge check; retain the regression cases so spaced and attached prefixes stay equivalent. Do we have a high-confidence way to reproduce the issue? Yes, at source level: a spaced Is this the best way to solve the issue? Yes. Re-trimming only after the SMS-specific prefix removal is the narrowest maintainable repair and avoids changing shared phone parsing outside the affected extension. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against 075030c19eb2. Label changesLabel justifications:
Evidence reviewedPR surface: Source +3, Tests +4. Total +7 across 2 files. View PR surface stats
What I checked:
Likely related people:
What the crustacean ranks mean
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. How this review workflow works
|
|
Merged via squash.
|
Co-authored-by: chatgpt-codex-connector[bot] <199175422+chatgpt-codex-connector[bot]@users.noreply.github.com> Co-authored-by: Peter Steinberger <[email protected]>
This is OpenClaw’s 111,111th pull request. :)
What Problem This Solves
Fixes an issue where SMS users could provide a documented prefixed phone number with a space after the
sms:ortwilio-sms:prefix and have OpenClaw normalize it into an invalid double-plus phone number.For example,
sms:+1 (555) 123-4567already normalized correctly, but the visually equivalent copied formsms: +1 (555) 123-4567normalized to++15551234567. That then failed SMS phone validation and could break explicit outbound targets, allowlist entries, and Twilio/RCS-style inbound sender normalization paths that reuse the SMS phone helper.Why This Change Was Made
The fix stays inside the SMS-local phone normalizer and trims the value again after removing the optional
sms:/twilio-sms:prefix. Existing punctuation and spacing tolerance inside phone numbers is unchanged; this only handles whitespace introduced between the prefix separator and the phone number.This avoids broad shared E.164 helper changes and keeps the behavior scoped to SMS prefixes that this extension already accepts.
User Impact
Users can now paste or configure SMS targets and allowlist entries in either attached or spaced prefixed form, such as
sms:+15551234567orsms: +15551234567, and get the same canonical E.164-ish normalized number.This makes SMS sender matching and explicit sends more forgiving without changing final validation: normalized numbers still must match the existing
+followed by 7-15 digits rule.Evidence
Before/after behavior from a local probe:
User-realistic call chain:
Validation: