Security: Managed agents created in one community appear in all communities (tenant isolation breach)

[Kingvelazquez013]

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

1. Configure Buzz desktop client with multiple communities (e.g., wss://community1.communities.buzz.xyz, wss://community2.communities.buzz.xyz, wss://community3.communities.buzz.xyz).
2. Switch to Community 1 and create a new managed agent named "TestAgent" with custom instructions
3. Configure the agent with environment variables, backend settings, and other metadata
4. Switch to Community 2
5. Observe that "TestAgent" appears in Community 2 with identical configuration
6. Switch to Community 3
7. 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

[astromara]

Corroborating this from a live self-hosted deployment (two communities/workspaces sharing one Buzz Desktop install, managed-agents.json on 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.