fix(cli): buzz messages send --content - publishes an empty message when stdin is empty; should be a hard error

[dziduchm]

Summary

buzz messages send --channel <UUID> --content - reads the message body from stdin. When stdin is empty, the command exits 0, the relay accepts the event, and an empty kind-9 message is published to the channel. Publishing an empty message should be a hard CLI error.

This is not hypothetical: one of our community agents constructed a broken shell pipeline and silently published an empty reply. The agent's own model output was fine; the pipeline was wrong; the CLI happily notarized and published a whitespace-only message.

Repro

# publishes an empty message, exit 0, relay accepts:
printf '%s\n' "$UNSET_VAR" | buzz messages send --channel <UUID> --content -

Result observed in relay DB: kind-9 event with content = a single newline, accepted: true, and the CLI's own success JSON reports "message": "":

{"accepted":true,"event_id":"f94d7886...","mention_pubkeys":[],"message":""}

Why it matters

• An agent (or script) that mis-constructs its pipe gets a success response for an empty publish. Nothing in the exit code or the JSON flags the emptiness, so the caller has no signal to retry
• The channel then shows a ghost empty bubble; recipients see "Buzzy: (empty)"
• --content - exists precisely so callers can stream content safely; a silent empty-input pass-through undermines that contract

Suggested fix

In the --content - path, after reading stdin to EOF: if the trimmed content is empty (or whitespace-only), fail with a non-zero exit and an error like error: empty message content from stdin; nothing published. Same guard for empty --content "" passed inline.

Optionally: a --allow-empty escape hatch if some legitimate use exists, though I can't think of one; an empty message has no recipient value and the relay could equally reject it server-side.

Environment

• buzz CLI / desktop 0.5.23 (also observed on 0.5.20), Linux, self-hosted relay
• Observed 2026-09-07, relay event f94d788668d37014f1e4b7f3280ba7d61c71c1d4001d1db83a1f9a23c0e7373d (content: single \n)

Related

• buzz-acp: hermes-agent ACP turns complete successfully but reply never publishes to the channel #4923, feat(agents): auto-respawn (or inbound-driven wake) for a crashed buzz-acp pair; detection is UI-poll-driven only #7425: agent reply-delivery reliability cluster; this is the third way a reply can silently fail or mislead