Switching community on one machine propagates/overwrites agent persona templates on other machines, and mints auto-started impostor agent identities
- Dominant language
- Rust
- Stars
- 32.7k
- Forks
- 4.3k
- Avg merge
- 1d 13h
- Merged PRs (30d)
- 253
Description
**Component:** Buzz Desktop (macOS + Windows), managed agents / persona templates
**Setup:** one user, two machines (Machine A: macOS; Machine B: Windows), member of two communities. Each machine runs its own managed agents (one instance per community, distinct keys).
## Summary
Changing the active community on Machine B emits sync events that modify Machine A's `agents/managed-agents.json` (and vice versa), with four distinct harmful effects we observed and measured between Aug 3 and Aug 13, 2026:
1. **Template overwrite across machines.** Persona templates on the remote machine are overwritten with the local machine's templates — `name`, `display_name` and avatar included. Because instances re-copy the persona's name via `persona_source_version`, a running agent's public display name gets clobbered: our PM agent's key published three different names in 8 days. Two templates on Machine A were renamed and re-avatared in the same second as a community switch on Machine B (timestamps match to the second).
2. **Templates travel even without a team link.** Templates whose `source_team_persona_slug` is `None` on the origin machine arrive on the other machine *with* that field populated. Decoupling an instance to a private template protects the instance's anchor, but does not stop the template copy itself.
3. **Impostor identities minted and auto-started.** When copied templates arrive orphaned on Machine B, the app minted NEW instances with NEW keypairs for them (`start_on_app_launch: true`), which started themselves ~4 seconds later and published relay profiles with the same display name and the same avatar (byte-identical data-URI) as the original agent on Machine A. Machine A's app, in the same situation, garbage-collects the orphan template instead — the two platforms behave differently. Resolving the agent's name now returns two visually indistinguishable keys. These minted instances also store their `private_key_nsec` in plaintext in `managed-agents.json` (agent instances created normally do not keep their key there).
4. **The same switch deletes local templates.** The community change that copied templates in also deleted Machine B's own templates, leaving existing instances pointing at nonexistent personas (shown as "Unknown" in the UI).
Additionally: built-in templates are re-seeded on every app start and cannot be deleted or hidden, so they are permanently exposed to being clobbered by the sync (ours are currently named after the *other* machine's agents); and the @-mention selector lists non-member agents (including dead/retired profiles) alongside channel members, labeled "not in channel", which makes misfires easy.
## Impact
Agent identity integrity. A mention resolved by display name can route to the wrong key; impostor keys with identical name+avatar persist in relay searches indefinitely; a user cannot tell which card the settings UI will write to (selection does not persist and the UI does not confirm the target).
## Steps to reproduce (as observed)
1. Two machines, same user, two communities; managed agents on both.
2. On Machine B, switch active community.
3. On Machine A, watch `agents/managed-agents.json`: template records are overwritten/renamed within seconds (no user action on Machine A).
4. Switch back on Machine B: Machine B's own templates are deleted, Machine A's templates arrive, and (on Windows) new keypair instances are minted for them and auto-started.
## Workaround that held
Giving every instance its own non-builtin private template (editing `managed-agents.json` with the app closed) makes the *instances* immune — verified through several subsequent community switches on both machines. It does not stop template copies from arriving, and builtins remain exposed.
## Asks
1. Community switch should not propagate persona templates to other machines (or only with an explicit team link).
2. Never mint + auto-start an instance (a new keypair) for an orphaned incoming template; align Windows behavior with macOS GC.
3. Allow hiding/deleting built-in templates, or stop re-seeding them every launch.
4. Don't keep `private_key_nsec` in plaintext for minted instances.
5. Mention selector: separate members from non-members harder than a "not in channel" tag.
**Related:** #3204 (cross-machine mention resolution).
Contributor guide
Assessment
This issue has not been assessed yet.