Split out of #4839 at @TheSeydiCharyyev's suggestion — that PR fixes mention visibility and deliberately doesn't touch the start path. This is the start path.
Setup
Self-hosted relay, six communities. 25 agents run as containers on my own VM, each its own buzz-acp with its own key. The desktop never spawns any of them and holds none of their keys. Desktop 0.5.5 on Windows 11.
What I did
I wanted the agents to show up in the Agents tab, so I hand-wrote entries into %APPDATA%\xyz.block.buzz.app\agents\managed-agents.json — one per agent, start_on_app_launch: false, auto_restart_on_config_change: false, backend: {"type":"provider","id":"...","config":{}}, no env_vars.
They showed up. And mentions broke.
What happens
Mention one of them in a channel it's already a member of, hit send:
Could not start agent mention: Backend · Claude: agent b0d474ab…7188 has no
private key available — the OS keyring may be unreachable. Refusing to start
without an identity; retry once the keyring is reachable.
The message is never published. Not delayed, not queued — useMentionSendFlow returns before the send, so it's gone. The agent is sitting right there in the channel and would have answered.
The keyring is fine, by the way. There's just no key in it for that agent, and there never will be — the key lives on the server.
Two paths reach it. ensureManagedAgentMentionsReady calls startAgentMutation for a participant it considers not-running, and attachManagedAgentToChannel does the same via ensureRunning for a non-participant. A provider-backed agent whose status isn't deployed takes the start branch in both.
Why the status is never deployed
Because nothing sets it. There's no provider binary for my setup and there isn't going to be one — docs/remote-agents.md puts the provider on the desktop's machine, and the point of running the agents on the server is that the desktop stays a client with no deploy credentials on it. So the record claims a provider that doesn't exist, the app believes it, and tries to launch it.
That's my fault for writing a record that isn't true. But there's no honest thing to write instead: there's no way to register an agent as display-only. #4833 hit the same wall from the other side.
Expected
A mention should publish. Starting an agent locally is an optimization — if it can't happen, the mention is still a valid mention, and the relay will route it to whoever is listening.
Concretely, either of these would fix it for me:
- Treat a start failure as non-fatal for the send: log it, publish the mention anyway.
- Or give the record a way to say "don't manage me" — a flag, or honouring
start_on_app_launch: false as "never auto-start", which is what I meant when I set it.
I've been running the first as a local patch (skip the start branch for a known backend id) across six communities for a week. Mentions publish, the agents answer, nothing else changed.
Not asking for
A provider for Docker. The relay directory already carries everything the client needs.
Split out of #4839 at @TheSeydiCharyyev's suggestion — that PR fixes mention visibility and deliberately doesn't touch the start path. This is the start path.
Setup
Self-hosted relay, six communities. 25 agents run as containers on my own VM, each its own
buzz-acpwith its own key. The desktop never spawns any of them and holds none of their keys. Desktop 0.5.5 on Windows 11.What I did
I wanted the agents to show up in the Agents tab, so I hand-wrote entries into
%APPDATA%\xyz.block.buzz.app\agents\managed-agents.json— one per agent,start_on_app_launch: false,auto_restart_on_config_change: false,backend: {"type":"provider","id":"...","config":{}}, noenv_vars.They showed up. And mentions broke.
What happens
Mention one of them in a channel it's already a member of, hit send:
The message is never published. Not delayed, not queued —
useMentionSendFlowreturns before the send, so it's gone. The agent is sitting right there in the channel and would have answered.The keyring is fine, by the way. There's just no key in it for that agent, and there never will be — the key lives on the server.
Two paths reach it.
ensureManagedAgentMentionsReadycallsstartAgentMutationfor a participant it considers not-running, andattachManagedAgentToChanneldoes the same viaensureRunningfor a non-participant. A provider-backed agent whosestatusisn'tdeployedtakes the start branch in both.Why the status is never
deployedBecause nothing sets it. There's no provider binary for my setup and there isn't going to be one —
docs/remote-agents.mdputs the provider on the desktop's machine, and the point of running the agents on the server is that the desktop stays a client with no deploy credentials on it. So the record claims a provider that doesn't exist, the app believes it, and tries to launch it.That's my fault for writing a record that isn't true. But there's no honest thing to write instead: there's no way to register an agent as display-only. #4833 hit the same wall from the other side.
Expected
A mention should publish. Starting an agent locally is an optimization — if it can't happen, the mention is still a valid mention, and the relay will route it to whoever is listening.
Concretely, either of these would fix it for me:
start_on_app_launch: falseas "never auto-start", which is what I meant when I set it.I've been running the first as a local patch (skip the start branch for a known backend id) across six communities for a week. Mentions publish, the agents answer, nothing else changed.
Not asking for
A provider for Docker. The relay directory already carries everything the client needs.