NanoClaw
NanoClaw’s explicit-destination migration can silently drop every reply from older chat groups
A NanoClaw update required named destinations on every send, but did not backfill the owning chat for existing wirings. One operator found six of eight pre-update groups affected: fresh sessions produced addressed output, then the poll loop dropped it because no destination existed.
nanocoai/nanoclaw issue #3140 is the inspected primary source: “Explicit-destinations migration: pre-existing wirings have no own-chat destination — all replies silently dropped after update.” Issue #3140 follows an install upgraded from a May-era base to 2.1.53 on Raspberry Pi 5 with native WhatsApp and Telegram. The breaking destination contract requires every send_message and send_file block to name a target. New wirings create an own-chat destination, but the update path left pre-existing messaging_group_agents rows without corresponding agent_destinations. Six of eight wired groups therefore logged Unknown destination and output had no deliverable message blocks. The warnings existed only in ephemeral container logs, so host logs and the user experience looked like ordinary silence. Manually adding one group destination per wiring and restarting each group container restored delivery. Adjacent PR #3137 adds self-service wiring controls, while PR #3139 fixes a separate shared-number filter that silenced the owner’s own messages.
The facts
- nanocoai/nanoclaw issue #3140 was created 2026-07-26T22:09:31Z and updated 2026-07-26T22:09:31Z; state is open. - nanocoai/nanoclaw returned 30378 GitHub stars, 853 open issues, default branch main, and last push 2026-07-26T15:23:04Z. - Latest tagged-release baseline checked: v2.1.17 published 2026-06-17T14:51:14Z. - Issue #3140 follows an install upgraded from a May-era base to 2.1.53 on Raspberry Pi 5 with native WhatsApp and Telegram. - The breaking destination contract requires every send_message and send_file block to name a target. - New wirings create an own-chat destination, but the update path left pre-existing messaging_group_agents rows without corresponding agent_destinations. - Six of eight wired groups therefore logged Unknown destination and output had no deliverable message blocks. - The warnings existed only in ephemeral container logs, so host logs and the user experience looked like ordinary silence.
What changed
Issue #3140 follows an install upgraded from a May-era base to 2.1.53 on Raspberry Pi 5 with native WhatsApp and Telegram. The breaking destination contract requires every send_message and send_file block to name a target. New wirings create an own-chat destination, but the update path left pre-existing messaging_group_agents rows without corresponding agent_destinations. Six of eight wired groups therefore logged Unknown destination and output had no deliverable message blocks. The warnings existed only in ephemeral container logs, so host logs and the user experience looked like ordinary silence. Manually adding one group destination per wiring and restarting each group container restored delivery. Adjacent PR #3137 adds self-service wiring controls, while PR #3139 fixes a separate shared-number filter that silenced the owner’s own messages. The primary record was inspected with its timestamps, state, body, and adjacent project records. ClawCharts supplied the assignment list; it does not establish the claim.
Why it matters
A migration that changes addressing semantics must migrate address state or fail loudly before accepting turns. Silent output disposal is worse than a rejected update because inference succeeds, cost accrues, and the operator receives no durable clue. Existing users carry exactly the state a fresh-install test omits. The operational test is whether persisted state, visible control, and runtime behavior agree at the handoff where authority changes.
Current
The migration report and both adjacent PRs were open. NanoClaw’s latest tagged baseline remained v2.1.17, while the report names a later merged install state. This brief therefore treats the behavior as current mainline/update risk, not as a defect proven in the last stable tag. Repository metadata, current issues and pull requests, release baseline, Hacker News discovery, and the rendered ranking row were checked. Weak search residue and historically used source spines were not promoted.
Evidence
The primary URL is https://github.com/nanocoai/nanoclaw/issues/3140. Supporting links are inspected current project records that establish implementation, adjacent direction, or boundary conditions. Dates, reproductions, test totals, and deployment observations remain attributed to their authors unless this brief explicitly says they were independently rerun.
Source boundary
Open work is described as open, closed work as closed, and operator reports as reports. Closure can reflect a documentation decision or triage outcome; it is not silently translated into a shipped code fix. Ranking explains why the project was scanned; it does not prove correctness, adoption, or package behavior.
Operator take
Before upgrade, inventory every wiring and its own-chat destination. After upgrade, send a synthetic reply through each existing group and require a host-level failure if any output block names an unknown destination. Keep rollback and database backup available. Preserve a before-state receipt and verify the narrowest invariant where state changes. Do not broaden permissions or delete state merely because the visible symptom is inconvenient.
Caveat
Public project records are mutable. Source state was captured at publication time, and later revisions may change status, scope, or evidence. No source here authorizes automatic mutation of a reader’s deployment.
Source inspected; source state, environment, and release boundary remain explicit.