For roughly two weeks, Buzz’s mention menu offered both agents in #general but neither in #To Do on my laptop. Typing the names manually did not help. The message posted, but the intended recipient identities were not attached.
Clarence, my Claude Code agent, and Janet, my Codex-powered Hermes agent, helped investigate. They checked the relay and source code while I tested the menu on my laptop.
On November 3, 2026, we got both names back by removing and re-adding each existing agent, followed by a refresh.
The short version
- Repair one agent’s membership in the affected channel, then refresh before testing again.
- Re-add the existing agent. Do not create another agent with the same name.
- This worked for both agents in our setup. The source code supports a role-related explanation, but we did not capture the laptop’s internal state.
How did we get the agent names back?
In the affected channel, remove one existing agent, re-add that same agent through Buzz Desktop’s agent flow, then refresh Buzz before testing the mention menu. This sequence restored both agents on my laptop. If you try it, confirm that you can manage channel membership and add the agent back first.
- Remove one agent from the affected channel’s member list.
- Re-add the same agent through Desktop.
- Refresh Buzz, type the mention symbol, and select the agent’s actual suggestion.
Send a short test and check for a response before repeating the procedure for another agent. Removing an agent temporarily interrupts its access to that channel, so choose a quiet moment.
We did not need to recreate the agents, reinstall Buzz, or delete application data.
What does the source code tell us?
In the Buzz 0.5.28 source Clarence and Janet reviewed, the directory builder can use a channel’s signed bot membership entry to discover an agent. It also recognizes certain owner-declared agents without that role. Separate channel-eligibility and response-policy checks apply to relay-discovered agents. Ordinary membership and mention eligibility are therefore different checks.
The role difference matched our symptom. The relay checks showed both agents recorded as bot in #general, where mentions worked, and as ordinary member entries in #To Do, where they did not. After the remove-and-re-add procedure, both were recorded as bot in #To Do too.
That gives us a source-backed explanation for why re-adding helped. It does not prove that the laptop had no usable owner record, or exclude every other discovery failure. We did not record those inputs before the repair.
The practical recommendation is firm: the sequence restored the selector twice. The exact causal diagnosis needs that qualification.
Why did we almost dismiss the repair?
After re-adding the first agent, the relay check showed that its role had changed to bot. The laptop still omitted it from the selector. We treated that as evidence against the role explanation before testing a refreshed client. After I refreshed Buzz, the name appeared.
I repeated the sequence for the second agent. Its name appeared too.
The source allows a previously successful directory result to remain usable while a refetch is in progress. That is consistent with an interface temporarily showing old suggestions. It does not establish that a manual refresh is always required or that a completed background refetch cannot update the list.
In our case, refreshing was the missing step. We should have tried it before expanding the investigation.
Should you clear application data if mentions fail?
We did not need to clear application data to recover these mentions. Start with the smaller channel-level repair and refresh rather than deleting folders. On our agent-hosting Mac, Buzz’s Application Support folder contains managed-agent state, so treating that whole folder as disposable cache would be an unnecessarily broad reset.
We also corrected our earlier cache advice. Inspecting storage on the host Mac did not establish what the affected laptop had loaded in memory.
If the sequence does not work in your setup, keep the existing agent identities and investigate further. Check the affected client rather than assuming that a working agent host proves the laptop has the same view.
Our mistake was simple: we checked the server-side change, saw an unchanged screen, and stopped one test too soon. Refresh the client before deciding that the repair failed.