# 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](/mcp/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](https://github.com/openclaw/wacli/issues/355) · 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](https://github.com/openclaw/wacli/issues/307) · 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](https://github.com/openclaw/wacli/issues/301) · 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](https://github.com/openclaw/wacli/issues/418) · 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: 
```shell
> 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: 
```go
// 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 <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…

[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](https://github.com/openclaw/wacli/issues/70) · 2026-02-20 · closed · external user · 1 comment

The remaining reports are on [the project's issue tracker](https://github.com/wacli-me/wacli-me/issues).