`contacts check` has no delegate through the follow socket, so it cannot run next to `sync --follow` (v0.18.2)

[ceifa]

Problem

wacli sync --follow holds the store lock for its whole lifetime, so wacli contacts check from another process always fails:

$ wacli contacts check <number> --json
{"success":false,"data":null,"error":"store is locked (another wacli is running?): store locked: resource temporarily unavailable (pid=601468 ...)"}

--lock-wait does not help. The follow process never releases the lock, so the wait always times out.

What already works

The send delegate socket (send_ipc.go) solves exactly this for 12 kinds: text, file, voice, sticker, react, location, poll, poll_vote, button_list_select, presence, edit and mark_read (#361, #380).

contacts check has the same shape. It is a live IsOnWhatsApp lookup: one query, one answer, no write to the local store. The invoking command validates and normalizes the numbers before the call and formats the result after it, like the delegated kinds do today.

Request

Add a delegated kind for contacts check, as #380 did for mark-read.

Use case

An agent keeps sync --follow running for live messages and webhooks, and shells out to wacli for actions. Sends, reactions and read state go through the delegate. Checking whether a number is registered on WhatsApp before writing to it is the one call left that forces stopping the sync unit and starting it again, which leaves the webhook dead for the length of the call.

The local mirror covers part of it: contacts search <number> answers for a number already synced, without touching the lock. A number the store has never seen still needs the live lookup, and that is the case where the check is worth making.

Tested on 0.18.2, Linux.

[clawsweeper]

Codex review: keeping this open for maintainer follow-up; there is still a little grit to resolve. Reviewed September 15, 2026, 7:38 PM ET / 23:38 UTC.

Summary
The requested capability remains absent on main and in v0.18.2. The linked read-state delegation work is a useful precedent, but does not cover contact registration lookups; no matching open implementation PR was found.

Reproducibility: yes. source establishes the reported lock failure: run contacts check against the same store held by sync --follow. No live account commands or tests were executed.

Maintainer decision needed

Question	Recommendation
Should contacts check join the operations supported through the follow daemon's existing delegate socket?	Extend existing delegation: Support registration checks through the existing socket with direct/delegated parity and documented daemon restart requirements.

Why: The current documented contract limits delegation to named operations; this request adds a supported execution capability rather than repairing a promised one.

Next step
Confirm support for the additional delegated operation before commissioning a focused implementation; this is not eligible for strict bug-fix dispatch.

Review details

Best possible solution:

Reuse the same-store delegate socket and registration helper, preserving per-input results, unknown responses, writable-mode checks, bounded execution, and clear older-daemon errors.

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

Yes, source establishes the reported lock failure: run contacts check against the same store held by sync --follow. No live account commands or tests were executed.

Is this the best way to solve the issue?

Yes, extending the existing delegate is the narrowest apparent implementation path; local contact search cannot answer registration queries for unseen numbers.

AGENTS.md: found and applied where relevant.

Codex review notes: model internal, reasoning medium; reviewed against 6f64e5923bc8.

Label changes

Label changes:

• add P2: This bounded capability gap interrupts concurrent automation but does not prevent standalone registration checks.
• add impact:ux-friction: Checking an unseen number currently requires stopping and restarting the follow process.
• add issue-rating: 🦞 diamond lobster: Current issue advisory state selects this label.
• add clawsweeper:source-repro: Current issue advisory state selects this label.
• add clawsweeper:no-new-fix-pr: Current issue advisory state selects this label.
• add clawsweeper:needs-maintainer-review: Current issue advisory state selects this label.
• add clawsweeper:needs-product-decision: Current issue advisory state selects this label.

Label justifications:

• P2: This bounded capability gap interrupts concurrent automation but does not prevent standalone registration checks.
• impact:ux-friction: Checking an unseen number currently requires stopping and restarting the follow process.

Evidence reviewed

What I checked:

• Current contact-check path: runContactsCheck requires writable mode, requests the store lock, and immediately returns initialization errors without trying delegation. Normalization and registration lookup happen only after connecting. (cmd/wacli/contacts_check.go:86, 6f64e5923bc8)
• Lock ownership explains the failure: newApp acquires the lock before constructing the app; sync retains that lock throughout its run and starts the delegate socket after connecting. (cmd/wacli/sync.go:71, 6f64e5923bc8)
• Delegation contract is explicitly limited: The delegate dispatcher supports sends, presence, edits, and mark_read, but no registration lookup. docs/sync.md lists supported commands without contacts check; docs/contacts.md promises a live lookup but does not promise operation alongside follow. (cmd/wacli/send_ipc.go:286, 6f64e5923bc8)
• Release remains affected: The v0.18.2 contact-check source has the same direct lock acquisition and immediate error return. The release notes announce delegation for chat read state only. (cmd/wacli/contacts_check.go:95, cd4370388f03)
• Merged precedent is distinct: GitHub confirms feat(ipc): delegate chats mark-read through follow socket (#361) #380 merged as e854bc5. Its scope is mark-read and mark-unread, resolving Delegate chats mark-read through the send delegate socket in follow mode #361 rather than registration checks. (cmd/wacli/chats_state.go:130, e854bc56b161)
• Feature history and routing: Merged feat: add contacts check for live WhatsApp registration lookup #331 by steipete established the live registration command and explicitly required a writable authenticated session. Commit metadata also identifies Myke Matos on the subsequent read-state delegation work. Deeper follow/blame inspection encountered unavailable historical objects, so source-line introduction attribution remains unverified. (cmd/wacli/contacts_check.go, db46a1e4a782)

Likely related people:

• steipete: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)
• Myke Matos: Suggested for follow-up; no historical authorship or introduction is verified. (role: unverified routing candidate; confidence: low)

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.