Skip to content

[codex] Add WhatsApp group listen windows#110947

Draft
NehoraiHadad wants to merge 1 commit into
openclaw:mainfrom
NehoraiHadad:codex/whatsapp-temporary-listen-window
Draft

[codex] Add WhatsApp group listen windows#110947
NehoraiHadad wants to merge 1 commit into
openclaw:mainfrom
NehoraiHadad:codex/whatsapp-temporary-listen-window

Conversation

@NehoraiHadad

@NehoraiHadad NehoraiHadad commented Jul 18, 2026 •
edited
Loading

Copy link
Copy Markdown

What Problem This Solves

WhatsApp group agents currently have two practical modes: wake only on each mention, or wake on every message with /activation always. In real group conversations, users often mention the agent once and then continue with follow-up messages without repeating the mention, so the agent misses the rest of the short exchange unless the owner switches the whole group to always-on.

This PR adds an opt-in middle ground for allowed WhatsApp groups: a temporary listen window after a valid mention. It keeps the existing group allowlist and sender authorization gates intact, and only relaxes mention gating for the same account, agent, session, and group JID while the window is active.

Summary

  • add listenAfterMentionMs and listenAfterMentionMaxMs per WhatsApp group entry
  • admit follow-up messages during the configured window and extend up to the configured cap
  • clear the active window on /activation mention without reopening it from the command turn
  • document the behavior and add focused tests for admission, cap expiry, command clearing, and schema parsing

Evidence

  • git diff --check
  • npm exec -- oxfmt --check docs/channels/group-messages.md extensions/whatsapp/src/auto-reply/monitor/group-listen-window.ts extensions/whatsapp/src/auto-reply/monitor/group-gating.ts extensions/whatsapp/src/auto-reply/monitor/group-gating.audio-preflight.test.ts extensions/whatsapp/src/config-schema.test.ts src/config/types.whatsapp.ts src/config/zod-schema.providers-whatsapp.ts
  • npm exec -- oxlint --tsconfig config/tsconfig/oxlint.extensions.json extensions/whatsapp/src/auto-reply/monitor/group-listen-window.ts extensions/whatsapp/src/auto-reply/monitor/group-gating.ts extensions/whatsapp/src/auto-reply/monitor/group-gating.audio-preflight.test.ts extensions/whatsapp/src/config-schema.test.ts
  • npm run test -- extensions/whatsapp/src/auto-reply/monitor/group-gating.audio-preflight.test.ts extensions/whatsapp/src/config-schema.test.ts

Note: pnpm lint:extensions could not complete in this local shell because pnpm is unavailable; focused npm exec oxlint was used instead.

@openclaw-barnacle openclaw-barnacle Bot added docs Improvements or additions to documentation channel: whatsapp-web Channel integration: whatsapp-web triage: needs-pr-context Candidate: external PR body lacks required problem context or evidence. size: M and removed triage: needs-pr-context Candidate: external PR body lacks required problem context or evidence. labels Jul 18, 2026
@clawsweeper clawsweeper Bot added rating: 🦪 silver shellfish Thin PR readiness signal; proof, validation, or implementation needs work. status: 📣 needs proof The PR needs real behavior proof before ClawSweeper can clear the contributor ask. P3 Low-priority cleanup, docs, polish, ergonomics, or speculative work. merge-risk: 🚨 compatibility 🚨 May break existing users, config, migrations, defaults, or upgrade paths. labels Jul 18, 2026
@clawsweeper

clawsweeper Bot commented Jul 18, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

Codex review: needs real behavior proof before merge. Reviewed July 19, 2026, 2:41 AM ET / 06:41 UTC.

Summary
The branch adds opt-in per-group WhatsApp listen windows that temporarily admit follow-up messages after a valid mention, with schema, documentation, and focused tests.

PR surface: Source +161, Tests +139, Docs +5. Total +305 across 7 files.

Reproducibility: not applicable. as a bug reproduction: this PR proposes a new WhatsApp group-activation capability. A real after-fix scenario is still needed to substantiate the implementation behavior claimed by the contributor.

Review metrics: 1 noteworthy metric.

  • WhatsApp group settings: 2 added persisted config fields. Both fields change the supported per-group activation contract and require an explicit compatibility and product decision before merge.

Merge readiness
Overall: 🦪 silver shellfish
Proof: 🦪 silver shellfish
Patch quality: 🦐 gold shrimp
Result: blocked until stronger real behavior proof is added.

Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch.

Rank-up moves:

  • Attach redacted real WhatsApp evidence showing the mention, an admitted unmentioned follow-up, expiry, and /activation mention clearing.
  • Obtain maintainer confirmation that this durable per-group activation mode belongs in the supported WhatsApp configuration contract.

Proof guidance:

  • [P1] Needs stronger real behavior proof before merge: The contributor describes a successful sanitized local WhatsApp run, but the comment does not attach redacted live logs, terminal output, a transcript, recording, or another inspectable artifact showing the after-fix path; add one before merge and redact private identifiers or secrets. Updating the PR body should trigger re-review; otherwise a maintainer can comment @clawsweeper re-review. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.

Risk before merge

  • [P1] Merging introduces a persisted per-group setting that expands when an allowed WhatsApp group can invoke the agent after a mention; maintainers should explicitly accept the activation, restart, and operational semantics before treating it as a supported product contract.
  • [P1] The stated live verification is not independently inspectable, so the claimed same-account/session/group scoping and follow-up admission remain unproven for review purposes.

Maintainer options:

  1. Approve the durable activation mode with proof (recommended)
    Accept the default-off configuration contract only after a maintainer confirms the product direction and the PR includes redacted live evidence for the intended group-scoping and reset behavior.
  2. Decline the new config surface
    Keep mention and always as the supported group activation modes if a third persisted admission policy is not desired.

Next step before merge

  • [P1] A maintainer must decide whether the new persisted WhatsApp activation mode should exist; contributor-supplied real behavior proof is also still required before merge.

Maintainer decision needed

  • Question: Should OpenClaw support a persisted per-group WhatsApp listen-after-mention mode in addition to the existing mention and always activation modes?
  • Rationale: The patch is not only a local bug repair: it establishes two public configuration keys and a new group message-admission policy whose semantics become a compatibility contract.
  • Likely owner: steipete — Likely repository-level product-direction owner; direct feature-history attribution was unavailable in this read-only review environment.
  • Options:
    • Sponsor the opt-in policy (recommended): Accept the default-off per-group listen window as a supported WhatsApp mode, subject to attached real behavior proof and clear lifecycle semantics.
    • Keep the existing two modes: Decline the new configuration surface and close or redirect the feature request rather than adding a third group-activation contract.

Security
Cleared: The supplied diff changes WhatsApp gating, configuration, tests, and docs without adding dependencies, workflow permissions, secret handling, downloads, or package execution paths.

Review details

Best possible solution:

If product direction is approved, retain the opt-in default-off design, document its exact reset and restart semantics, and add a redacted live WhatsApp transcript or terminal/log capture demonstrating mention, unmentioned follow-up, window expiry, and /activation mention clearing.

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

Not applicable as a bug reproduction: this PR proposes a new WhatsApp group-activation capability. A real after-fix scenario is still needed to substantiate the implementation behavior claimed by the contributor.

Is this the best way to solve the issue?

Unclear. The branch places the behavior in the WhatsApp gating path and keeps it opt-in, but whether a permanent third activation mode and two new settings are the best supported product contract needs maintainer direction.

AGENTS.md: found and applied where relevant.

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

Label changes

Label justifications:

  • P3: This is a default-off feature addition rather than a confirmed regression or urgent user-facing failure.
  • merge-risk: 🚨 compatibility: The PR adds persisted WhatsApp group configuration that changes message-admission behavior for configured users and upgrades.
  • rating: 🦪 silver shellfish: Overall readiness is 🦪 silver shellfish; proof is 🦪 silver shellfish and patch quality is 🦐 gold shrimp.
  • status: 📣 needs proof: The PR needs real behavior proof before ClawSweeper can clear the contributor ask. Needs stronger real behavior proof before merge: The contributor describes a successful sanitized local WhatsApp run, but the comment does not attach redacted live logs, terminal output, a transcript, recording, or another inspectable artifact showing the after-fix path; add one before merge and redact private identifiers or secrets. Updating the PR body should trigger re-review; otherwise a maintainer can comment @clawsweeper re-review. After adding proof, update the PR body; ClawSweeper should re-review automatically. If it does not, the PR author or someone with repository write access can comment @clawsweeper re-review.
Evidence reviewed

PR surface:

Source +161, Tests +139, Docs +5. Total +305 across 7 files.

View PR surface stats
Area Files Added Removed Net
Source 4 162 1 +161
Tests 2 140 1 +139
Docs 1 6 1 +5
Config 0 0 0 0
Generated 0 0 0 0
Other 0 0 0 0
Total 7 308 3 +305

What I checked:

  • Proposed configuration surface: The PR adds listenAfterMentionMs and listenAfterMentionMaxMs to the WhatsApp group config type and Zod schema, making a new persisted per-group admission policy. (src/config/types.whatsapp.ts:30, d508693dec15)
  • Gating behavior: The branch resolves the window only when the group is not already always-active, clears it for an owner /activation mention command, and bypasses mention gating only while a matching window is active. (extensions/whatsapp/src/auto-reply/monitor/group-gating.ts:222, d508693dec15)
  • Proof follow-up: The contributor’s July 19, 2026 comment describes a sanitized local WhatsApp run and an accepted follow-up, but it contains no redacted log excerpt, terminal capture, transcript, recording, or linked artifact that can independently show the after-fix behavior. (d508693dec15)
  • Prior review continuity: The prior completed review had no code findings and requested real behavior proof; the current head remains d508693, so there is no prior code finding to re-raise. (d508693dec15)

Likely related people:

  • steipete: This PR requires a decision on whether WhatsApp should expose a new durable group-admission mode; direct feature-history attribution could not be completed from the read-only inspection environment. (role: likely product-direction owner; confidence: low; files: extensions/whatsapp/src/auto-reply/monitor/group-gating.ts, src/config/types.whatsapp.ts)
  • NehoraiHadad: Authored the branch and provided the only described live WhatsApp validation scenario; relevant for follow-up evidence, not as a substitute for current-main ownership history. (role: proposed implementation author; confidence: high; commits: d508693dec15; files: extensions/whatsapp/src/auto-reply/monitor/group-listen-window.ts, extensions/whatsapp/src/auto-reply/monitor/group-gating.ts)
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.

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.
Review history (2 earlier review cycles)
  • reviewed 2026-07-18T20:20:40.756Z sha d508693 :: needs real behavior proof before merge. :: none
  • reviewed 2026-07-18T21:03:30.922Z sha d508693 :: needs real behavior proof before merge. :: none

@NehoraiHadad

NehoraiHadad commented Jul 19, 2026

Copy link
Copy Markdown
Author

Live local behavior proof from a patched OpenClaw 2026.6.11 install. Sanitized to avoid exposing private WhatsApp content or identifiers.

Retest time: 2026-07-19 06:55-06:57 Asia/Jerusalem.

Observed sequence:

  • A group message with a valid mention reached the WhatsApp agent account and logged wasMentioned:true, listenWindowActive:false.
  • The runtime armed the listen window for durationMs:600000 with maxMs:1800000.
  • A later follow-up group message without a mention reached the same WhatsApp agent account and logged wasMentioned:false, listenWindowActive:true.
  • The runtime re-armed/extended the window after that follow-up.
  • The HadadBot agent processed the follow-up and replied, confirming the message was not dropped by the mention gate.

I also saw a separate local duplicate-route issue on another WhatsApp account in the same test group, producing reply session initialization conflicted for that other route. That did not affect the agent account path above and appears to be local configuration overlap, not a failure of the listen-window behavior in this PR.

@clawsweeper re-review

@clawsweeper

clawsweeper Bot commented Jul 19, 2026 •
edited
Loading

Copy link
Copy Markdown
Contributor

🦞🧹
ClawSweeper re-review requested.

I asked ClawSweeper to review this item again.
Action: item re-review queued (workflow sweep.yml, event repository_dispatch).
Result: the existing ClawSweeper review comment will be edited in place when the review finishes.

Re-review progress:

@BradGroux BradGroux mentioned this pull request Jul 19, 2026
Draft
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 docs Improvements or additions to documentation merge-risk: 🚨 compatibility 🚨 May break existing users, config, migrations, defaults, or upgrade paths. P3 Low-priority cleanup, docs, polish, ergonomics, or speculative work. rating: 🦪 silver shellfish Thin PR readiness signal; proof, validation, or implementation needs work. size: M status: 📣 needs proof The PR needs real behavior proof before ClawSweeper can clear the contributor ask.

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

1 participant

@NehoraiHadad