Repository navigation
Security: Managed agents created in one community appear in all communities (tenant isolation breach) #7184
Description
Describe the bug
Managed agents created in Community 1 automatically appear in Community 2 and Community 3 with the same name, instructions, environment variables, and full configuration. This is a tenant isolation breach — agents and their sensitive configurations should be scoped only to the community where they were created.
Steps to reproduce
- Configure Buzz desktop client with multiple communities (e.g., wss://community1.communities.buzz.xyz, wss://community2.communities.buzz.xyz, wss://community3.communities.buzz.xyz).
- Switch to Community 1 and create a new managed agent named "TestAgent" with custom instructions
- Configure the agent with environment variables, backend settings, and other metadata
- Switch to Community 2
- Observe that "TestAgent" appears in Community 2 with identical configuration
- Switch to Community 3
- Observe that "TestAgent" appears in Community 3 with identical configuration
Expected behavior
- Agent created in Community 1 should exist only in Community 1
- Switching to Community 2 should show a different (likely empty) set of agents
- An agent from Community 1 should not be accessible, visible, or executable from Community 2 or Community 3
- Each community maintains its own isolated set of managed agents
- The agent's sensitive data (instructions, environment variables, credentials) is not exposed across tenant boundaries
Root cause
Managed agents are stored in a single local file (managed-agents.json) that is not scoped by community. When the desktop client loads agents, it reads this single file for all communities equally, causing agent definitions to be visible
wss://community1.communities.buzz.xyz
Reacted by David Cruwys
Activity
fix(desktop): scope managed-agent roster per community (block#7184)
fix(desktop): scope managed-agent roster per community (block#7184)
fix(desktop): scope managed-agent roster per community (block#7184)
astromara commentedon Sep 11, 2026
Corroborating this from a live self-hosted deployment (two communities/workspaces sharing one Buzz Desktop install,
managed-agents.jsonon disk).Additional destructive side effect not yet captured above: deduplicating one workspace's agent dropdown by deleting the duplicate record actually deletes the shared record outright — since both workspaces point at the same entry in
managed-agents.json, removing "the duplicate" from Workspace A's picker also unregisters that agent from Workspace B entirely. There's no per-workspace delete; the file has no field to scope a delete to one community. In our case this took Fizz/Honey/Pollen out of a workspace that had nothing to do with the cleanup.Related: the file is rewritten on app quit, which can clobber an edit made to it while Buzz is still running — a race that likely compounds the duplicate problem, since a fix applied live can be silently reverted on next quit/relaunch.
Net effect: today the only way to de-duplicate the dropdown is to collapse both workspaces onto one shared identity per persona (one Fizz, one Honey, etc., used by both communities), which forfeits any workspace-local identity/history. Scoping
managed-agents.json(or the picker query) by community, as suggested above, would fix both the display bug and this delete hazard.fix(desktop): dedupe roster, clear empty community files, key files b…