Renaming an agent in one community renames a different agent (different keypair) in another community

[wfrank2509]

Summary

Two managed agents that have different keypairs and live in different communities share a single persona record. Renaming one of them renames the other. The agent identity is scoped per community and per install; the definition that names it is install-global and keyed by a value that is byte-identical everywhere.

Observed with two agents created from the built-in Welcome Team, on two separate machines and two separate relays.

Not a data-exposure issue

Stating this up front so severity is not misjudged: KIND_PERSONA (30175) is a member of SHARED_GATED_KINDS (crates/buzz-core/src/kind.rs:215), so persona events are author-only unless they carry exactly ["shared","true"], enforced at every relay read chokepoint. System prompts do not become readable across communities, no identity signs on the wrong relay, and no message crosses. What crosses is configuration — display name, and by the same path prompt/model/runtime.

Reproduction

1. Install the built-in Welcome Team.
2. Create an agent from one of its personas in Community A. It gets its own keypair.
3. Create an agent from the same persona in Community B (separate relay; a second machine makes it more visible). It gets a different keypair.
4. Rename the agent in Community A via the Agents view.
5. The agent in Community B is renamed too.

Root cause — three factors converging

1. The definition store is install-global.
agents/personas.json, agents/managed-agents.json, and agents/teams.json are one file per install, with no per-community partition — while agents/retention/ is correctly partitioned into one database per community. The isolation boundary was drawn at events but not at definitions.

2. Editing an agent edits the shared persona.
The Agents view routes the edit through updatePersonaAndPublish (desktop/src/features/agents/ui/usePersonaActions.ts:195) — the shared definition, not the per-pubkey managed-agent record.

3. The persona d-tag is the bare team slug.
persona_d_tag (desktop/src-tauri/src/managed_agents/persona_events.rs:65) prefers source_team_persona_slug and only falls back to the record's UUID id. Every persona sourced from a built-in team therefore keys on a slug that is identical across every community and every install.

apply_inbound_persona (desktop/src-tauri/src/commands/personas/inbound.rs:342) then overwrites display_name, avatar_url, system_prompt, runtime, model, provider, respond_to, and parallelism on whatever record matches that d-tag.

rename in Community A
  → patches the one global persona keyed by the team slug
  → agent in Community B (different keypair, different relay) is renamed

The managed-agent path is correctly scoped by contrast — its d-tag is the agent pubkey (inbound.rs:365), so those events never collide.

Relay sync is not required to trigger this

The shared local file alone is sufficient: both agents resolve the same persona record on the same install. The kind:30175 sync (inbound.rs:22 — "so Device B inherits Device A's edits") extends the same collision across machines, but is not the origin.

This also means the per-community retention scoping does not mitigate it, even though that scoping is otherwise correct.

Suggested fix

Real fix: scope the persona d-tag. persona_d_tag should mix in the community (and arguably the install) rather than returning the bare team slug, so two agents instantiated from the same built-in persona in different communities occupy different coordinates.

Cheap mitigation: make the managed agent's own name authoritative for presentation, so a persona behaves as a template applied at creation rather than a live binding.

Worth deciding explicitly which of these is intended, since "built-in personas stay in sync across my devices" is plausibly a feature for the single-community case — but it should not reach across communities.

Not verified

I traced the Agents view to the persona update path but did not step through which exact form field the rename submits. The empirical behaviour (rename crosses communities) is confirmed; the precise UI field binding is inferred.

Line references are against 6c16354.