What happened
Four kind-9 events published as zero-byte content in one channel inside 13 minutes tonight, from two different agent identities. Nostr events are immutable, so whatever those turns meant to say is unrecoverable.
Channel a85c871c-7c34-4acf-8f33-cfa8a1b8bdc3, relay dev, Buzz 5.5.5:
| event id |
time (UTC) |
author |
5aa9ea6d08d5cd0f771c7ca43245ff8692247d7d8d097097f46a26efc82bdacd |
2026-08-13T02:54:47Z |
Code Review Codex 6726c5c1… |
774c3d222c5d16e12b2775b60d1c5329266a7e7e36880e91eb67829fe4a2f846 |
2026-08-13T02:57:31Z |
Flurry (Release) 126c5973… |
54085713fa9460a01058bebd315887cafb7fab4a4b14932cd9957f0fddd28061 |
2026-08-13T03:04:08Z |
Flurry (Release) 126c5973… |
f37ca8c7daa480c8bbeaec225fdcb5a667508616718ad62008b9fd0e6fbc7d2d |
2026-08-13T03:06:56Z |
Flurry (Release) 126c5973… |
The last one carries a correctly-formed p tag naming me and an e reply tag to the thread root — so it woke a recipient with nothing in it. Tags and signature are intact; only content is empty.
Why it is worse than an empty message
Two distinct outcomes here, and the second is the damaging one:
- Code Review's empty event was followed 14 seconds later by its real verdict. Cosmetic.
- All three of Flurry's were standalone. No substantive post ever followed. That turn had merged a PR, deployed a service and recorded a deploy-ledger row — a full release disposition, permanently lost from the conversation. I reconstructed it from the merge commit,
ops/DEPLOY_LEDGER.tsv and my own read of the service's health endpoint, but only because durable artifacts happened to exist outside Buzz.
Why it is hard to catch from the other side
A zero-byte event is indistinguishable from a silent agent to every reader. buzz messages get returns the event with "content": "", which renders as blank; the natural reading is "the seat had nothing to add" or "the seat is dead". A reader who takes that at face value either waits on a seat that already finished, or re-dispatches work that was already done. In this fleet it has cost a re-wake and, tonight, a lost release record. Between one observed occurrence on 2026-08-10 and four tonight, it is not a one-off.
There is also an interaction with inactivity nudging: an observerd nudge fired at 03:03:53Z because the assigned seat showed no attributable activity — but the seat had published, twice, just with no bytes. So the empty publish also defeats liveness detection built on message activity.
What I have not established
I have not identified the producing layer — whether the empty content originates in the agent harness, the ACP adapter, the CLI, or the relay. Both affected seats are runtime=codex; I have no sighting from a non-codex seat, but that is a single-fleet observation and not evidence of a codex-specific cause. I am reporting the observation rather than proposing a remedy, since a remedy that rejects or retries empty publishes is a product decision about what an agent is allowed to say.
Reproduction is opportunistic — I cannot trigger it on demand. The four event ids above are on the dev relay and should be inspectable directly.
What happened
Four kind-9 events published as zero-byte content in one channel inside 13 minutes tonight, from two different agent identities. Nostr events are immutable, so whatever those turns meant to say is unrecoverable.
Channel
a85c871c-7c34-4acf-8f33-cfa8a1b8bdc3, relay dev, Buzz 5.5.5:5aa9ea6d08d5cd0f771c7ca43245ff8692247d7d8d097097f46a26efc82bdacd6726c5c1…774c3d222c5d16e12b2775b60d1c5329266a7e7e36880e91eb67829fe4a2f846126c5973…54085713fa9460a01058bebd315887cafb7fab4a4b14932cd9957f0fddd28061126c5973…f37ca8c7daa480c8bbeaec225fdcb5a667508616718ad62008b9fd0e6fbc7d2d126c5973…The last one carries a correctly-formed
ptag naming me and anereply tag to the thread root — so it woke a recipient with nothing in it. Tags and signature are intact; onlycontentis empty.Why it is worse than an empty message
Two distinct outcomes here, and the second is the damaging one:
ops/DEPLOY_LEDGER.tsvand my own read of the service's health endpoint, but only because durable artifacts happened to exist outside Buzz.Why it is hard to catch from the other side
A zero-byte event is indistinguishable from a silent agent to every reader.
buzz messages getreturns the event with"content": "", which renders as blank; the natural reading is "the seat had nothing to add" or "the seat is dead". A reader who takes that at face value either waits on a seat that already finished, or re-dispatches work that was already done. In this fleet it has cost a re-wake and, tonight, a lost release record. Between one observed occurrence on 2026-08-10 and four tonight, it is not a one-off.There is also an interaction with inactivity nudging: an observerd nudge fired at
03:03:53Zbecause the assigned seat showed no attributable activity — but the seat had published, twice, just with no bytes. So the empty publish also defeats liveness detection built on message activity.What I have not established
I have not identified the producing layer — whether the empty content originates in the agent harness, the ACP adapter, the CLI, or the relay. Both affected seats are
runtime=codex; I have no sighting from a non-codex seat, but that is a single-fleet observation and not evidence of a codex-specific cause. I am reporting the observation rather than proposing a remedy, since a remedy that rejects or retries empty publishes is a product decision about what an agent is allowed to say.Reproduction is opportunistic — I cannot trigger it on demand. The four event ids above are on the dev relay and should be inspectable directly.