Describe the bug
Buzz can present an actionable dangerous-command approval message even though the command has been irreversibly truncated. The user is told to reply /approve, /approve session, or /approve always, but cannot inspect the hidden part of the operation.
This occurred with an external Hermes Agent identity posting an approval request into a Buzz channel. The visible message was:
⚠️ Dangerous command requires approval:
ssh -o BatchMode=yes <server> 'set -u; printf "VERIFY_UNIT\n";
systemd-analyze verify <unit>; printf "EXIT_STATUS_78\n";
systemd-analyze exit-sta...
Reason: recursive delete
Reply `/approve` to execute this one operation, `/approve session` to approve this
pattern for the session, `/approve always` to approve permanently, or `/deny` to cancel.
The hidden tail was the security-critical part: the risk classifier reported recursive delete. There was no expand/details action and copying the code block returned only the truncated text.
I queried the raw event from the Buzz relay. It also contained only the truncated command, so this was not merely visual clipping in the Desktop component. The upstream agent had already shortened the payload before publishing it. Its own append-only audit transcript independently stored the same call as …(+1060 chars), so the full operation could not be reconstructed from either system.
The command eventually timed out without executing. No deletion occurred.
This report is intentionally scoped as an integration/fail-closed problem rather than attributing sender-side truncation to Buzz: Buzz received incomplete text, but still presented an approval path with no way for the user to establish what /approve would authorize.
Steps to reproduce
- Connect an external agent/gateway to a Buzz channel.
- Have it request approval for a long shell command whose text is shortened before publication, while retaining approval instructions such as
/approve.
- Open the approval message in Buzz Desktop.
- Try to expand, inspect, or copy the complete command.
- Observe that only the truncated text is available, even though the message still invites approval.
Expected behavior
A dangerous operation must be fail-closed unless Buzz possesses the complete immutable approval payload.
Suggested contract/UX:
- Approval requests should use a structured event containing the complete command/operation, risk explanation, unique operation ID, and digest—not only prose in a chat message.
- The Desktop should render the complete command in a scrollable, copyable details view.
- If the sender marks the payload truncated, or the complete structured payload is absent, Buzz should show Cannot approve: incomplete command and expose only Deny.
- Approval should bind to the operation ID and digest shown to the user. A stale
/approve must never authorize a different current request.
session or always approval should display the exact derived pattern and scope before confirmation.- Read-only checks and state-changing cleanup should be represented as separate operations rather than one bundled approval.
- The complete approval payload and final decision should remain available in an owner-visible audit record, with secret redaction that does not remove command structure.
At minimum, the UI should provide a prominent warning when an approval-looking message contains explicit truncation markers such as a trailing ... or …(+N chars). A structured protocol is preferable because text heuristics cannot prove completeness.
Actual behavior
Buzz displayed an incomplete command followed by instructions to approve it. Neither the Desktop nor the relay event provided the omitted 1,060 characters. The user therefore had to choose between blindly approving a command classified as a recursive deletion or abandoning the operation.
Version and platform
- Buzz version: 0.5.3
- OS: macOS 26.6
- Integration: external Hermes Agent gateway using a self-hosted Buzz relay
Logs / additional context
- Approval request timestamp: 2026-08-03 11:45 local time
- Request expired after five minutes without consent
- Terminal result:
BLOCKED: Command timed out without user response. The user has NOT consented to this action.
- Raw relay event was inspected and confirmed to contain only the truncated command
- No credentials, private keys, tokens, or full hostnames are included in this public report
Security principle: an approval prompt is not meaningful consent unless the user can inspect the complete operation that the approval will authorize.
Describe the bug
Buzz can present an actionable dangerous-command approval message even though the command has been irreversibly truncated. The user is told to reply
/approve,/approve session, or/approve always, but cannot inspect the hidden part of the operation.This occurred with an external Hermes Agent identity posting an approval request into a Buzz channel. The visible message was:
The hidden tail was the security-critical part: the risk classifier reported
recursive delete. There was no expand/details action and copying the code block returned only the truncated text.I queried the raw event from the Buzz relay. It also contained only the truncated command, so this was not merely visual clipping in the Desktop component. The upstream agent had already shortened the payload before publishing it. Its own append-only audit transcript independently stored the same call as
…(+1060 chars), so the full operation could not be reconstructed from either system.The command eventually timed out without executing. No deletion occurred.
This report is intentionally scoped as an integration/fail-closed problem rather than attributing sender-side truncation to Buzz: Buzz received incomplete text, but still presented an approval path with no way for the user to establish what
/approvewould authorize.Steps to reproduce
/approve.Expected behavior
A dangerous operation must be fail-closed unless Buzz possesses the complete immutable approval payload.
Suggested contract/UX:
/approvemust never authorize a different current request.sessionoralwaysapproval should display the exact derived pattern and scope before confirmation.At minimum, the UI should provide a prominent warning when an approval-looking message contains explicit truncation markers such as a trailing
...or…(+N chars). A structured protocol is preferable because text heuristics cannot prove completeness.Actual behavior
Buzz displayed an incomplete command followed by instructions to approve it. Neither the Desktop nor the relay event provided the omitted 1,060 characters. The user therefore had to choose between blindly approving a command classified as a recursive deletion or abandoning the operation.
Version and platform
Logs / additional context
BLOCKED: Command timed out without user response. The user has NOT consented to this action.Security principle: an approval prompt is not meaningful consent unless the user can inspect the complete operation that the approval will authorize.