Summary

On every gateway startup and WhatsApp reconnect, the log emits:

[WARN] [web-session] restored corrupted WhatsApp creds.json from backup

However, creds.json and creds.json.bak are byte-identical — there is no actual corruption. The detection logic in auth-store-*.js (maybeRestoreCredsFromBackup) appears to have a false-positive condition.

Observed Behavior

• Every single WhatsApp connection (fresh start or reconnect after status 499) triggers this warning
• diff creds.json creds.json.bak shows zero differences
• creds.json is valid JSON with all expected fields
• WhatsApp connects successfully after the "restore" — it is functionally harmless
• When combined with the reconnect loop (see below), this generates hundreds of false warnings in the error log

Environment

• OpenClaw: 2026.4.2
• OS: macOS 25.3.0 (ARM64, Mac mini M1)
• Node: v25.6.1
• WhatsApp account type: Personal (linked device)

Expected Behavior

The corruption check should compare actual file content/validity rather than triggering unconditionally on startup. If the file is valid JSON with the expected schema, no warning should be emitted.

Log evidence

2026-04-02T20:41:10.186-07:00 [WARN] [web-session] restored corrupted WhatsApp creds.json from backup
2026-04-02T20:42:14.402-07:00 [WARN] [web-session] restored corrupted WhatsApp creds.json from backup
2026-04-02T20:43:18.013-07:00 [WARN] [web-session] restored corrupted WhatsApp creds.json from backup
...repeats every ~60 seconds during reconnect loop

Related

This is amplified by the reconnect storm issue (filed separately).