# A server restart can no longer eat your queued Telegram messages

When you message your agent while its server is down (an update restart, a crash window), the lifeline — the small always-on process that talks to Telegram — queues the message and replays it when the server comes back. To protect itself from a genuinely poisonous message (one that crashes the server every time it's delivered), the replay gives up on a message after 3 failed attempts, records it in a dropped-messages file, and asks the sender to resend.

The bug: a failed attempt counted toward those 3 strikes **even when the failure had nothing to do with the message** — the server was simply down. Replay runs on a ~30-second tick, so during a multi-minute restart window the message at the head of the queue collected its 3 strikes in about 90 seconds and was dropped, every time. On a day with frequent fleet releases this was a message-shredder: Codey's dropped-messages file shows 39 dropped messages, 9 on 2026-06-05 alone, every single one stamped "Handoff to server failed" — including the mentor's coaching messages, which silently vanished mid-apprenticeship (the mentee responded to some instructions and never saw others, and nobody could tell why).

The codebase already understood this exact principle in a sibling case: when the server and lifeline are on incompatible versions (the "version skew" episode), replay failures explicitly do NOT count toward the drop budget, because they're systemic, not message-specific. This fix extends the same reasoning to the down-server case: a replay failure now only counts toward the 3 strikes **when the supervisor believes the server is healthy** and it still refused the message — which is the only situation the poison-message policy was designed for. When the server is known-down, the message is re-queued with its strike count untouched and simply waits for the server to return.

One line of behavior change, mirroring an existing exemption, pinned by source-guard tests in the same suite that pinned the version-skew exemption. The drop path itself (record + loud notice + ask-to-resend) is unchanged for genuinely poisonous messages.
