Reported issues for whatsapp by wacli-me
Pod holds 10 of 10 GitHub reports that passed its relevance review. This can include external user reports, maintainer-confirmed bugs, and concrete feature gaps. Treat them as evidence to inspect, not a count of distinct defects.
Back to whatsapp by wacli-me.
Most discussed
Auth silently ignores whatsmeow passkey events, blocking accounts that require second-stage linking
Summary
wacli auth cannot complete authentication for WhatsApp accounts placed in
the newer passkey-gated companion-linking flow.
The first QR scan is accepted by the phone, but WhatsApp then displays:
Scan the QR code again to link
Scanning the next QR emitted by wacli results in:
Check your connection and try again.
The network connection is stable. Removing the saved WhatsApp passkey does not restore legacy pairing, and the same failure occurs with a clean session store.…
Read the thread · 2026-08-14 · open · external user · 3 comments
v0.13.0: send text --reply-to rejects stored PDF/document messages
Summary
In wacli v0.13.0, send text --reply-to fails before sending when the referenced stored message is a PDF/document.
The same workflow succeeds in v0.12.0 and has rendered the document quote box on the recipient device. This appears to be a compatibility regression in the stricter quoted-message construction introduced after #301.
Environment
- wacli: v0.13.0 official macOS arm64 release (release SHA256 and code signature verified)
- OS: macOS arm64
- Store: authenticated…
Read the thread · 2026-07-18 · closed · external user · 3 comments
send text --reply-to: message delivers but the quote is silently dropped (0.11.1)
Summary
wacli send text --reply-to <msgID> reports success and delivers the message, but the quote is silently dropped — the recipient sees a plain message with no quoted-reply box.
Because the CLI returns {"ok": true, ...} and the message really does arrive, nothing looks wrong from the command line. Only a visual check on the recipient's phone reveals that the reply context is missing. That silent-success behaviour is the main reason I'm filing this: automation cannot detect the…
Read the thread · 2026-07-13 · closed · external user · 3 comments
libsignal diagnostics corrupt JSON command output on stdout
Observed
On main at 41c9cce050b1bcfa5b167708d5b86221c15969b1, libsignal diagnostics are written to stdout alongside wacli output. A malformed Signal message can therefore add non-JSON lines to a successful JSON result.
wacli configures the whatsmeow logger, but not libsignal's separate global logger. The pinned go.mau.fi/libsignal v0.2.2 default logger uses fmt.Println for INFO, WARNING and ERROR. This does not mean every JSON command is affected: a libsignal diagnostic must occur…
Read the thread · 2026-09-13 · closed · outside contributor · 2 comments
invalid uri authority error on Windows upon wacli auth
Hello, I tried using wacli 0.12.0 for the first time on my Windows 10 computer, and got the following error:
> wacli auth
create schema_migrations table: invalid uri authority: C:%5CUsers%5Cme%5C.wacli%5Cwacli.db?_foreign_keys=on&_busy_timeout=5000
According to Claude, this could be a fix:
// internal/sqliteutil/files.go
func FileURI(path, rawQuery string) string {
p := filepath.ToSlash(path)
if len(p) > 1 && p[1] == ':' { // Windows: C:/Users/... -> /C:/Users/...
p…
[Read the thread](https://github.com/openclaw/wacli/issues/303) · 2026-07-14 · closed · external user · 2 comments
### QR auth fails with "Can't link new device at this time" - WhatsApp Web works fine
## Summary
Running `wacli auth` displays the QR code, but when scanning with WhatsApp (both personal and business accounts), it shows the error: **"Can't link new device at this time, try again later"**.
Importantly, **WhatsApp Web QR codes work perfectly fine** when tested in a browser, so this appears to be specific to wacli's authentication protocol.
## Steps to Reproduce
1. Run `wacli auth`
2. QR code displays successfully
3. Open WhatsApp on phone → Settings → Linked Devices → Link a…
[Read the thread](https://github.com/openclaw/wacli/issues/30) · 2026-02-03 · closed · external user · 2 comments
### `contacts check` has no delegate through the follow socket, so it cannot run next to `sync --follow` (v0.18.2)
### Problem
`wacli sync --follow` holds the store lock for its whole lifetime, so `wacli contacts check` from another process always fails:
$ wacli contacts check
`--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…
[Read the thread](https://github.com/openclaw/wacli/issues/425) · 2026-09-15 · open · outside contributor · 1 comment
### `ResolveLIDToPN` has no CLI surface: a consumer holding an unresolved `@lid` must read whatsmeow's `whatsmeow_lid_map` directly (v0.18.2)
`ResolveLIDToPN` is wired into six commands and applied automatically to stored rows and webhook
payloads, but nothing takes a `@lid` and hands back the phone JID. A consumer that holds a lid the
store has not already rewritten has no supported way to resolve it, so the only route is reading
whatsmeow's own `whatsmeow_lid_map` table out of `session.db`.
This is the same shape as #359 (`group_participants` had a writer and no reader), which
`groups participants list` closed in 0.18.0 — one…
[Read the thread](https://github.com/openclaw/wacli/issues/420) · 2026-09-13 · open · outside contributor · 1 comment
## Most recent
### Webhook payloads carry WhatsApp's media retrieval material (`MediaKey`, `DirectPath`, `FileEncSHA256`) to every consumer (v0.18.2)
`sync --webhook` posts WhatsApp's media retrieval material — `MediaKey`, `DirectPath`,
`FileEncSHA256` (and `FileSHA256`) — to the webhook endpoint on every media message. Together
those are enough to fetch the attachment from WhatsApp's CDN and decrypt it. They are not in the
documented payload shape, and a consumer that never downloads media receives them anyway, on
every image, video, audio and document that crosses the bridge.
## Observed (main @ 41c9cce, v0.18.2)
A media message pushed…
[Read the thread](https://github.com/openclaw/wacli/issues/417) · 2026-09-13 · open · outside contributor · 1 comment
### Store lock prevents sending while sync is running
## Problem
When `wacli sync --follow` is running (continuous listener), attempting to `wacli send text` fails with:
store is locked (another wacli is running?): resource temporarily unavailable
The only workaround is to stop the sync process, send the message, then restart sync:
```bash
pkill -f "wacli sync" && sleep 2
wacli send text --to "GROUP_JID" --message "hello"
wacli sync --follow &
This works but it's clunky, risks missing messages during the gap, and adds complexity…
Read the thread · 2026-02-20 · closed · external user · 1 comment
The remaining reports are on the project's issue tracker.