Desktop 0.5.14: send-time mention revalidation silently strips p tags for own locally-managed agents (fail-closed regression from #5681) #6147

Desktop 0.5.14: send-time mention revalidation silently strips p tags for own locally-managed agents (fail-closed regression from #5681)

Symptom

On stock Buzz Desktop 0.5.14 (macOS, Apple Silicon), a channel message that mentions my own locally-managed agent posts with the @Name text intact but no p tag in the event. The agent (subscribe=Mentions) is never addressed and never responds. No UI warning, no error — the message looks correctly tagged in the thread.

The same message, same identity, same channel, same relay, sent from the mobile app carries the p tag and wakes the agent immediately.

• 100% reproducible on Desktop since updating to 0.5.14 (every agent mention, every channel)
• Mobile is unaffected
• Agents are locally managed on the same machine that runs Desktop — this is not the remote/second-install discovery problem from Managed agents are only mentionable from the machine that runs them #3277 / Desktop: a second install of the same identity cannot address agents at all — empty mention picker, hidden members, and typed mentions silently drop the p tag (mobile unaffected) #5264 / [Bug] Desktop 0.5.14 omits an authorized cross-owner bot member from @mention autocomplete #6022. The agent appears in the mention picker normally; the tag is dropped at send time.

Relay-side A/B evidence

From the relay's stored events, identical text sent minutes apart by the two clients:

(Relay is a self-hosted private relay with NIP-42 WS auth and the NIP-98 POST /query HTTP bridge; both verified healthy. No event IDs included since the relay is private.)

Suspected cause

bcf353c / PR #5681 ("enforce agent mention authorization at send boundaries", first shipped in 0.5.14) added desktop/src/features/messages/lib/agentMentionRevalidation.ts. Before every send it re-fetches the managed-agent directory, the relay-agent directory (kind:10100 via the relay's POST /query bridge), and profile ownership — and fails closed: if any of those calls errors or returns not-ready, filterAdmittedMentionPubkeys(pubkeys, agentPubkeys, new Set()) strips all agent p tags while the @Name text is kept.

On a self-hosted private relay this appears to fail deterministically, so every agent mention is stripped. (The in-flight picker/eligibility PRs — #5361, #5549, #5375, #4546 — address the remote-agent discovery variant and do not touch this send-path gate.)

Workaround verified

A local build of the exact 0.5.14 release commit with the revalidation made a no-op pass-through (fail-open, 2 files) restores correct behavior: the p tag is present and the agent responds. So the regression is isolated to the new send-time revalidation path.

Suggestion

At minimum, don't fail silently: if mention tags are dropped at send time because authorization is unknown, surface an explicit error/toast instead of posting a message that looks addressed but isn't. Failing open (with the agent side still enforcing respond_to) matches pre-0.5.14 behavior and the mobile client's behavior.

Environment

• Buzz Desktop 0.5.14 (stock), macOS on Apple Silicon
• Self-hosted private relay (NIP-42 + NIP-98), single machine
• Agent is a locally managed agent owned and hosted by the reporter

Related: #3277, #5264, #6022, #5240 — this is the send-path regression variant, not the picker-discovery variant.