runtime[stderr]: StderrText a0d86fb8

[sliamh11]

Auto-reported runtime error (stub only — details stay local)

• Fingerprint: a0d86fb8a9ba5501
• Source: stderr (level 40)
• Error class (allow-listed): StderrText
• First seen: 2026-05-02 15:16:31 UTC
• Occurrences in first batch: 1

---

Filed by log_to_issue.py. Message text, stack frames, and any pino fields are NOT uploaded — this repo is public. Full scrubbed details are in ~/.config/deus/log_to_issue_details/a0d86fb8a9ba5501.json on the host. Additional occurrences are throttled to one comment/24h.

[sliamh11]

Stale — single occurrence, no recurrence in 3+ weeks. Closing. Reopen if the fingerprint resurfaces.

[sliamh11]

Still happening. Count: 6. Last seen: 2026-07-02 09:30:01 UTC.

[sliamh11]

Still happening. Count: 11. Last seen: 2026-07-07 06:52:56 UTC.

[sliamh11]

Still happening. Count: 20. Last seen: 2026-07-08 00:09:47 UTC.

[sliamh11]

Triaged against the local scrubbed details (a0d86fb8a9ba5501.json): 20 occurrences over ~2 months of libsignal's "Failed to decrypt message with any known session" (verifyMAC / doDecryptWhisperMessage in packages/mcp-whatsapp's vendored libsignal). This is known Baileys/libsignal behavior when an inbound message references a stale or unknown Signal session (e.g. sender re-registered, stale pre-keys) — the library logs it to stderr directly; it is not a Deus defect. Root-cause hygiene is tracked in LIA-351 (WhatsApp auth-dir bloat: 10.8k stale pre-keys in store/auth/). Closing as known library noise at low frequency (~10/month); reopen/refile if frequency spikes after the LIA-351 cleanup.

[sliamh11]

Still happening. Count: 22. Last seen: 2026-07-14 08:13:40 UTC.